你觉得同样需求实现,代码量少厉害还是代码量多厉害?

[crazyTanuki]

看到挺多公司喜欢考核代码量 kpi 的

[GeruzoniAnsasu]

用时短的厉害

[likang8210]

同事有行代码是这样的：Map<String, Map<Boolean, List<Map<String, Object>>>> categoryDatas = endData.stream() .... 这[categoryDatas] 变量是不是叼炸天，就两行，没注释

[Leviathann]

code is all about expressiveness

[witcat]

在真正高手如云的团队里，故意写的抽象，是会受排挤的...

[HB9527]

和代码量多少没有关系，是别人能不能快速看懂有关，架构清晰、结构清晰最好，毕竟代码是给人看的，编译之后是给机器运行的。

[bugmaker1024]

抽象的代码还是不要写，因为过段时间你自己再看的时候你自己都可能不知道当时不知道为什么这样写。清晰易懂最重要

[shyangs]

大神在代碼塞魔術數字 ，不寫註釋，一樣有人吹，比如 John D. Carmack 的魔法數字 0x5f3759df

高手如雲的 Linux 內核也一堆奇技淫巧.

[roundgis]

收錢多的厲害

[ox18]

不能一概而论吧

[pkoukk]

我觉得都不是，清晰易懂也就一般般
厉害的是架构里有足够的灵活度适应瞎 JB 改的需求
当产品很不好意思地说这个需求估计要七八天吧，我只需要两三天的时候，别提有 TM 多爽了

[silencil]

一个方法只做一件事的就是好代码，在我这是个很简单的判断标准。代码写的再好，又臭又长真的是看的头大，不好抓主要的点。

[tkHello]

无所谓 他司统计代码量

[wangedenr]

app 容量越小越厲害吧, 你看 apple 內建的 app 容量基本上都不大.

[jeffh]

@pkoukk #30 事实上产品只会说估计要半天吧，留下你在那里懵逼。代码清晰易懂才会少出 bug ，这才是重要的。

[ArleneCheung]

@crazyTanuki 你这个话让我想起我高数老师说的一句话，有的老师为了证明自己的在学术界不可撼动的地位，把可以讲的简单的知识讲难，但是听他课的学生可就遭殃了，这种人就叫没有师德。所以这跟一个公司的氛围有关系，有的人觉得你写的代码新来的应届生可以看懂，觉得你成就了新来的人才，有的就觉得你可以替代，格局放在这里，如果真的被这样的公司觉得自己是不可替代的，那走了也罢，此处不留爷自有留爷处。

[ArleneCheung]

@ArleneCheung 纠正一下，觉得自己是可以随便替代的。

[nekochyan]

当然是清晰易懂最重要，我们前端代码一大堆结构体，看起来代码很多，但实际都是大神写的脚本生成的，看起来多但是在此基础上编程真的方便易懂

[pkoukk]

@jeffh 你说的这种产品在我们这活不过三天

[Nazz]

首先看功能是否有缺陷, 然后是性能和可维护性

[gps949]

得具体情况具体分析，哪种好不一定，代码量属于“标”，只看标不看本就是扯淡。
因为即使看本的话也不存在单一标准：
1 、从技术本身角度：
- 稳定性，边界情况覆盖程度
- 性能
- 资源运用（并发、分布等）
- 资源占用（算力、存储等）
- 易用性
- 复用度
- 兼容性
- 标准化
- 安全性
……
2 、从人的角度：
- 团队协作度（规范标准化）
- 不可替代性（代码易读性）
- 可复用性
……

代码量多和少时可在这些标准做到各有优劣，并且也不存在唯一的对应性。比如代码多就一定易读或不易读吗？