代码有两个基本要求，一是完成了它该有的功能，二是结构清晰明了，方便后期维护。为KPI而疯狂“凑字数”，增加代码行数只会让代码不好读，不好用。
作者 | 路遥
审校 | 千山、云昭
现在有不少公司，以“代码量”作为程序员的KPI，程序员写的代码数目直接关系到这个月的工资。
这里可以用比尔·盖茨的一句话来说“用代码行数来衡量编程的进度，就如同用重量来衡量飞机的制造速度”。
此话题在51CTO技术社群里引发了热烈讨论。
【Isaac】作为公司的管理者，必须认识到，你考核什么，就会得到什么。也就是说，你在关注代码量的时候，代码量就会程爆炸式增长，但是并不意味着项目进度快了，反而可能是更慢了。
【梁飞】这样想呢？如果用C语言编程，写同样一句话：“hello world”用1行，用Python可能用10行，用Java可能用20行，这个咋衡量？而且不同级别的程序员写代码质量也不一样，就好比比尔·盖茨写Winodows底层代码，10行搞定了，执行效率很高，一个普普通通的程序员写了100行才搞定，而且执行效率低下。
【测试小秦】用代码量考核有点扯淡，容易造成代码冗余吧？质量不就差了。
【aiyo】肯定不合理, 拿这种当绩效考核，只会让简单的程序屎山化。最简单的增加代码行数就是减少函数复现，正常会把重复使用，或者同一个功能的代码封装成一个函数，要行数的话，就不会有人这么做了。把自己封装的函数在调用的时候直接把函数内容写进来。比如我一个函数int sum(int i[]); 里面内容有10行，在程序中我调用了50次，那我占的代码行数就是50行，如果我不封装这个函数，那我代码行数就是500行, 只看代码行数，那就只能做点无用功了。
1.代码多并不代表运行好代码少可能更利于软件的运行
代码有两个基本要求，一是完成了它该有的功能，二是结构清晰明了，方便后期维护。为KPI而疯狂“凑字数”，增加代码行数只会让代码不好读，不好用。
根据某平台统计的一组数据来看：
Linux的内核代码超2500万，经过完善，增加了2229836行代码，同时删除了2004759行代码，在增添了许多新功能的同时，删除了许多对旧的CPU架构的支持和内核中的其他无用代码。
可见，在软件的发展过程中，代码数量并不决定软件质量。如果想要一个软件持续发展下去，必然需要对已有代码进行重构和重写，减去那些无用冗杂的代码，以增加整个Codebase的易维护性。
研究表明，对于常用的编程语言，生产率似乎是固定的，但如果使用适当的高级语言，编程的生产率可以提高5倍。就拿现在还比较热门的编程语言Python和老牌编程语言Java来说，Java是比较繁琐的，同样的实现一个功能，Java需要很多行代码，但是Python可能就只要几行就可以实现了。
这一点从下面两个例子中就能看出：
打印Hello World
来源：51CTO博客
字符串处理
来源：51CTO博客
所以，在编程领域，高产出并不等于高价值。
2.用代码多少来评价程序员的贡献无疑是外行人的决定
有一个有趣的说法，程序员按字数考核算绩效，是沿袭稿费制度。如果按字数结算，那就玩命灌水，如果按页数结算，那就拼命换行。程序员绩效参考稿费的结算方式，得到的结果也不过如此。
程序员的工作并不是为了敲代码，程序员作为技术人员，编程能力、技术知识才是立足之本。代码是智慧的产物，代码的多寡和能实现的功能没有直接联系，创造代码是为了提高生产效率，所以代码的数量并不重要。
而且代码的行数其实很容易增加，换行、初始化、赋值、添加注释、大括号中括号小括号，或者多写无用的类和方法，甚至可以把第三方的源码引入到项目中。但优质代码是经过深思熟虑且极尽优化的结果，其迭代过程可能数次甚至数十次，这些努力在最终代码是看不到的。说实话，想增加行数有无数种方法。但结果是什么呢，代码规范被破坏，而代码质量却难以提高。编程的本质是解决问题，而不是书写垃圾代码。
在网上看见一个很有意思的例子，某一位非常优秀的程序员，别人100行代码才能完成的事儿，他10行就能搞定，但就因为公司搞起了按代码行评估绩效的制度，于是他开始把一行代码就能完成的功能，写成10行。
比如一个给定两点计算矩形面积的函数，原本他写成这样一行代码：
double getRectAreaByPoints(double x1, double y1, double x2, double y2){ return abs((x1 - x2)*( y1- y2));}1.（来源：知乎@安晓辉）
现在他会写成这样：
doublegetRectAreaByPoints(
double x1,
double y1,
double x2,
double y2){
double width;
width = x1 - x2;
if(width < 0)
{
width = -width;
}
double height;
height = x2 - y2;
if(height < 0)
{
height = -height;
}
double area;
area = width * height;
if(area == 0)
{
return 0;
}
else {
return area;
}}1.2.3.4.5.6.7.8.9.10.11.12.13.14.15.16.17.18.19.20.21.22.23.24.25.26.27.28.29.30.31.32.33.34.35.36.37.38.39.40.（来源：知乎@安晓辉）
这么一看，弊端就很明显了，很多程序员把重心放在了如何增加代码行数上，而不是如何编写高质量代码上，甚至会有人不惜一切代价换取代码量，大量复制粘贴，完全不考虑复用，从而产生大量垃圾代码。
所以，代码的行数并不适合作为工作量的衡量标准。
3.程序员的贡献应从多方面来评估
一个项目麻烦的地方往往在与框架的搭建功能、需求分解功能以及后续的功能测试，代码只占其中工作的一部分。代码能力可以随着经验和时间的增多而提高，但算法逻辑能力和架构能力则不会这样，这两样才是衡量程序员能力的重要标准，但这些“能力”无法计算。
所以对于程序员的绩效考核，KPI标准应该复杂一些，不能单纯的统计代码行数，可以从代码的质量，发现Bug的数量，代码检测结果，单元测试覆盖度，项目中所担任的角色和工作量等多个方面考察得出。只有多方面考察得出的结果才能更真实的反映员工的工作能力，并以此激励程序员更加努力。
像是国内互联网大厂腾讯的绩效考核分为两部分，业务评价和组织管理评价，通俗点说就是业绩考核和行为考核，其中业绩考核的权重为70%，行为考核的权重为30%。虽说网上没有公布明确的考核标准，但是也可以看出他们的考核也是在多方位同时进行的。
责任编辑：武晓燕来源： 51CTO技术栈
