多low的组织才用代码量来考核绩效？4个真正有效的手段
阅读引导：
1、开发工作是一个脑力劳动，是虚拟工作，不能以量取胜。
2、更应该考虑的是如何促进代码质量。
就像小说名著，从来不靠字数取胜一样，开发工作也不能靠代码行数评价。
有人千百万字的堆砌，写出的是网络快餐文学。
有人短短几个字，却写出流传千古的词句。
也像解数学题一样，有人用了一大堆的公式算法，最好得不出正确结论，有人用简洁的算法，完美的解答问题。
开发工作，更像一种实施过程。
就像培训作者如何运用词句锻炼文笔，是一种过程，是一种手段。
应该用实施结果来评价过程。
而对于过程，更应该关注如何优化。
作为科技人员，个人向来信奉的是自动化、机器化。
如何促进、监控代码水平，有一点浅显的认识。
1
目前代码扫描的缺陷
目前的代码扫描工具，分为两大类。
首先是潜入到IDE开发工具插件，例如findbugs等静态扫描工具。
一般会扫描出代码的规范问题。
例如命名规范性，变量赋值处理等内容。
另外，就是以sonar为代表的全代码扫描。
这种扫描工具一般比较强大，会根据指定的库、规则去匹配查找。
例如，代码的安全问题等，都会查出来。
但是代码扫描工具有一个缺点，就是治标不治本。
总是以开发人员完成在代码基础上，去查漏补缺，修修补补。
对于代码结构性、根本性的提升并不多。
另外，我们不应该把代码扫描工具当做一种后补偿手段，如果能够在开发过程中就不断的提示能解决绝大部分问题。
尤其是，很多初级的开发人员，总是不喜欢写单元测试，无法保证交付出去的代码的质量。
为什么？
因为，初级人员写的代码，几乎没有结构化的理念，不符合面向对象的一系列原则，例如SOLID等。
一个类几十上百行，单元测试难度极大。
所以不愿意去做。
那么，通过一些工具，扫描代码，提示进行结构化的拆分，则能很大程度上解决这个问题。
2
能解决80%问题的4个有效手段
不要把过程（代码量）当成手段，要考察的是结果。并且不能过程来考核结果，而是应该优化过程，来提升结果质量。
个人经验，要想促进代码质量，顺带一揽子解决代码单元测试覆盖率意愿等问题。
应该从SOLID原则触发，思考手段。
每个方法的行数
无法给定一个确切的数字，说明一个方法多少行较好。
但是如果一个方法上百行代码，肯定是有问题的。
可以看一下一些优秀的开源框架，例如JUnit以及Spring等，每个方法十几行而已。
通过控制方法中代码行数，逼着进行拆分，从而贯彻单一职责理念。
而如果方法细分，贯彻了单一职责理念，那么就可以非常方便的进行单元化测试。
从而提升代码交付质量，进而有可能提升交付效能。
并且，也方便后续的修改。
类变动跟踪记录
如果一个类在频繁的修改，就不符合开闭原则了。
可以通过适当的手段记录，通知，以提升代码的设计。
代码相似度审查
另外一点，我们总是希望代码简洁，可复用。
不要在修改时，需要改动一大堆。
也是避免开发人员为了规避上一个类的变动跟踪记录，而不停的复制一份代码。
内聚性、耦合性数据评价
对于整个包的划分评价，已经有了理论基础。
在的Robert C. Martin的《敏捷软件开发：原则、模式与实践》一书中，早就提出了对于包的内聚性、耦合性评价方式。
在eclipse中也有对应的插件JDepend来量化。
简单来说：
对于稳定性的评价：
对于抽象性的度量：
具体的内容，请大家参阅书籍第20章包的设计原则。
这里不再赘述。
3
何谓深度思考
到了这里，具体手段讲述完了。
我想以此再扩展一点，什么叫做深度思考。
如果一个管理者，拿代码行数来考核开发人员，你是说他水平不行呢，还是没有经过深度思考？
所谓的深度思考，实际上是透过现象看本质，找到真正的目的、价值所在。
例如，代码行数的考核，根本的初始原因是什么？
真正想做的，是不是要促进代码质量？
进行深度思考的手段，很简单，就是“黄金思考圈”的方式。针对具体的问题，进行应用就好了。
所谓的黄金思考圈，就是我们认识世界的方法：
最外面的层面what层面，事情的表象，具体的客观事务。
中间的How层面，如何去做这个事情。
最核心的why层面，就是做的理念或者目的。