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

[crazyTanuki]

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

[qsnow6]

在团队中，在实现需求的前提下，清晰易懂最厉害。

[laoluo1991]

楼上正解

[brader]

没有看到具体代码之前无法评判，同样需求实现，我估计代码量差不了很多行数的，如果差出行数，那行数多的代码很可能做了更多的异常处理、数据校验。 所以代码这种东西，一定要分个高下，还是拿出来比一比才知道

[lcy630409]

能让别人（同级）看懂 能运行就是好代码

[crazyTanuki]

@qsnow6 但是也有一个可能,新来的实习生轻轻松松上手,显得你很菜...老板觉得实习生可以替代你,但代码绕,过度封装,层层跳转,实习生连试用期都过不了

[iyiluo]

可读性

[DigitalG]

赞同 1 楼，但 lz 显然说的是别的“厉害”，并不是在讨论技术。

[sankooc]

代码量考核 kpi... 冗余度计算在内么

[ljsh093]

@brader #3 我也觉得，给以后的需求多留点余地更好

[crazyTanuki]

@brader 异常处理,数据校验属于需求内了,不可能一个做处理一个不做处理这样对比代码量

[crazyTanuki]

@lcy630409 会不会没有护城河

[crazyTanuki]

@DigitalG 综合性吧,纯技术或者纯人情世故都太片面了

[crazyTanuki]

@sankooc 不计算,CV 的不算

[maocat]

没有注释我还能看的懂的代码最厉害

[crazyTanuki]

@maocat 其实这个规范命名就很容易看懂了,基本上都不需要注释

[tcpdump]

可维护、可扩展

[crazyTanuki]

@tcpdump 基本上面向对象或者函数式就能做到吧

[brader]

@crazyTanuki 那也会有差异化啊，就比如校验几个参数是否为空，有些后端喜欢用一个 if 或关系来判断，直接报参数错误，有些后端喜欢一个一个判断，告诉你哪个参数必须的。这两种做法都能实现需求，区别只在于对你的前端对接人报错是否友好，但是文档齐全的情况下，其实也没问题

[volatileSpark]

清晰易懂最厉害

[akring]

写出为难同行的代码并不能够成为你的护城河，因为大概率决定你去留的人，和接管你代码的人不是同一个。

最近的大型社会实验现场可以参见 Twitter 。