为了绩效，10行代码被我改成了500行...

来自公众号：51CTO技术栈

现在有不少公司，以“代码量”作为程序员的KPI，程序员写的代码数目直接关系到这个月的工资。

这里可以用比尔·盖茨的一句话来说“用代码行数来衡量编程的进度，就如同用重量来衡量飞机的制造速度”。

此话题在51CTO技术社群里引发了热烈讨论。

【Isaac】作为公司的管理者，必须认识到，你考核什么，就会得到什么。也就是说，你在关注代码量的时候，代码量就会程爆炸式增长，但是并不意味着项目进度快了，反而可能是更慢了。

【梁飞】这样想呢？如果用C语言编程，写同样一句话：“hello world”用1行，用Python可能用10行，用Java可能用20行，这个咋衡量？而且不同级别的程序员写代码质量也不一样，就好比比尔·盖茨写Winodows底层代码，10行搞定了，执行效率很高，一个普普通通的程序员写了100行才搞定，而且执行效率低下。

【测试小秦】用代码量考核有点扯淡，容易造成代码冗余吧？质量不就差了。

【aiyo】肯定不合理, 拿这种当绩效考核，只会让简单的程序屎山化。最简单的增加代码行数就是减少函数复现，正常会把重复使用，或者同一个功能的代码封装成一个函数，要行数的话，就不会有人这么做了。把自己封装的函数在调用的时候直接把函数内容写进来。比如我一个函数int sum(int i[]);  里面内容有10行，在程序中我调用了50次，那我占的代码行数就是50行，如果我不封装这个函数，那我代码行数就是500行, 只看代码行数，那就只能做点无用功了。

代码多并不代表运行好

代码少可能更利于软件的运行

代码有两个基本要求，一是完成了它该有的功能，二是结构清晰明了，方便后期维护。为KPI而疯狂“凑字数”，增加代码行数只会让代码不好读，不好用。

根据某平台统计的一组数据来看：

Linux的内核代码超2500万，经过完善，增加了2229836行代码，同时删除了2004759行代码，在增添了许多新功能的同时，删除了许多对旧的CPU架构的支持和内核中的其他无用代码。

可见，在软件的发展过程中，代码数量并不决定软件质量。如果想要一个软件持续发展下去，必然需要对已有代码进行重构和重写，减去那些无用冗杂的代码，以增加整个Codebase的易维护性。

研究表明，对于常用的编程语言，生产率似乎是固定的，但如果使用适当的高级语言，编程的生产率可以提高5倍。就拿现在还比较热门的编程语言Python和老牌编程语言Java来说，Java是比较繁琐的，同样的实现一个功能，Java需要很多行代码，但是Python可能就只要几行就可以实现了。

这一点从下面两个例子中就能看出：

打印Hello World

来源：51CTO博客

字符串处理

来源：51CTO博客

所以，在编程领域，高产出并不等于高价值。

用代码多少来评价程序员的贡献

无疑是外行人的决定

有一个有趣的说法，程序员按字数考核算绩效，是沿袭稿费制度。如果按字数结算，那就玩命灌水，如果按页数结算，那就拼命换行。程序员绩效参考稿费的结算方式，得到的结果也不过如此。

程序员的工作并不是为了敲代码，程序员作为技术人员，编程能力、技术知识才是立足之本。代码是智慧的产物，代码的多寡和能实现的功能没有直接联系，创造代码是为了提高生产效率，所以代码的数量并不重要。

而且代码的行数其实很容易增加，换行、初始化、赋值、添加注释、大括号中括号小括号，或者多写无用的类和方法，甚至可以把第三方的源码引入到项目中。但优质代码是经过深思熟虑且极尽优化的结果，其迭代过程可能数次甚至数十次，这些努力在最终代码是看不到的。说实话，想增加行数有无数种方法。但结果是什么呢，代码规范被破坏，而代码质量却难以提高。编程的本质是解决问题，而不是书写垃圾代码。

在网上看见一个很有意思的例子，某一位非常优秀的程序员，别人100行代码才能完成的事儿，他10行就能搞定，但就因为公司搞起了按代码行评估绩效的制度，于是他开始把一行代码就能完成的功能，写成10行。

比如一个给定两点计算矩形面积的函数，原本他写成这样一行代码：

double getRectAreaByPoints(double x1, double y1, double x2, double y2){ return abs((x1 - x2)*( y1- y2));}

左右滑动查看完整代码（来源：知乎@安晓辉）

现在他会写成这样：

double
getRectAreaByPoints
(
    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;
    }
}

（来源：知乎@安晓辉）

这么一看，弊端就很明显了，很多程序员把重心放在了如何增加代码行数上，而不是如何编写高质量代码上，甚至会有人不惜一切代价换取代码量，大量复制粘贴，完全不考虑复用，从而产生大量垃圾代码。

所以，代码的行数并不适合作为工作量的衡量标准。

程序员的贡献应从多方面来评估

一个项目麻烦的地方往往在与框架的搭建功能、需求分解功能以及后续的功能测试，代码只占其中工作的一部分。代码能力可以随着经验和时间的增多而提高，但算法逻辑能力和架构能力则不会这样，这两样才是衡量程序员能力的重要标准，但这些“能力”无法计算。

所以对于程序员的绩效考核，KPI标准应该复杂一些，不能单纯的统计代码行数，可以从代码的质量，发现Bug的数量，代码检测结果，单元测试覆盖度，项目中所担任的角色和工作量等多个方面考察得出。只有多方面考察得出的结果才能更真实的反映员工的工作能力，并以此激励程序员更加努力。

像是国内互联网大厂腾讯的绩效考核分为两部分，业务评价和组织管理评价，通俗点说就是业绩考核和行为考核，其中业绩考核的权重为70%，行为考核的权重为30%。虽说网上没有公布明确的考核标准，但是也可以看出他们的考核也是在多方位同时进行的。

关于如何评价代码质量的问题，在日前由51CTO主办的WOT全球技术创新大会2022-北京站上，自如技术平台保障中心总监应阔浩分享了自己的看法。

对于代码的质量需要从两个维度来看，一个是结果的指标，一个是过程的指标。

结果指标有很多标尺，比如说线上的Bug率、淘汰率、千行代码Bug率、故障时长等等都能反映出结果。而在过程指标当中，比如项目需求量的交付时长、有没有延期提测、Bug修改次数等等也都是需要考核的维度。

也就是说，光靠代码行数是不准的，我们需要一些其他指标，包括代码被引用的次数、函数是否整洁有序等等。

所以评价代码的质量需要从综合的维度来看，单凭一个维度是不准的，正如《技术人才的晋升管理之道》一文中，首汽约车技术总经理尹钊提到的那样，要从多个维度提升自己的能力，才是技术人晋升的正确方向。

如果非要程序员按行数算绩效，那也应当增加一项保底，即优秀代码的保障工资。这样才不会让优秀程序员寒心，鼓励程序员写出更优秀的代码，这样程序员们才能更认真更高效的完成代码编写，而不是只想疯狂“注水”。

--- EOF ---

推荐↓↓↓