作者 | 路遙

審校 | 千山、云昭

現在有不少公司，以“代碼量”作為程序員的KPI，程序員寫的代碼數目直接關系到這個月的工資。

這里可以用比爾·蓋茨的一句話來說“用代碼行數來衡量編程的進度，就如同用重量來衡量飛機的制造速度”。

此話題在51CTO技術社群里引發(fā)了熱烈討論。

【Isaac】作為公司的管理者，必須認識到，你考核什么，就會得到什么。也就是說，你在關注代碼量的時候，代碼量就會程爆炸式增長，但是并不意味著項目進度快了，反而可能是更慢了。

【梁飛】這樣想呢？如果用C語言編程，寫同樣一句話：“hello world”用1行，用Python可能用10行，用Java可能用20行，這個咋衡量？而且不同級別的程序員寫代碼質量也不一樣，就好比比爾·蓋茨寫Winodows底層代碼，10行搞定了，執(zhí)行效率很高，一個普普通通的程序員寫了100行才搞定，而且執(zhí)行效率低下。

【測試小秦】用代碼量考核有點扯淡，容易造成代碼冗余吧？質量不就差了。

【aiyo】肯定不合理, 拿這種當績效考核，只會讓簡單的程序屎山化。最簡單的增加代碼行數就是減少函數復現，正常會把重復使用，或者同一個功能的代碼封裝成一個函數，要行數的話，就不會有人這么做了。把自己封裝的函數在調用的時候直接把函數內容寫進來。比如我一個函數int sum(int i[]);  里面內容有10行，在程序中我調用了50次，那我占的代碼行數就是50行，如果我不封裝這個函數，那我代碼行數就是500行, 只看代碼行數，那就只能做點無用功了。

1.代碼多并不代表運行好代碼少可能更利于軟件的運行

代碼有兩個基本要求，一是完成了它該有的功能，二是結構清晰明了，方便后期維護。為KPI而瘋狂“湊字數”，增加代碼行數只會讓代碼不好讀，不好用。

根據某平臺統計的一組數據來看：

Linux的內核代碼超2500萬，經過完善，增加了2229836行代碼，同時刪除了2004759行代碼，在增添了許多新功能的同時，刪除了許多對舊的CPU架構的支持和內核中的其他無用代碼。

可見，在軟件的發(fā)展過程中，代碼數量并不決定軟件質量。如果想要一個軟件持續(xù)發(fā)展下去，必然需要對已有代碼進行重構和重寫，減去那些無用冗雜的代碼，以增加整個Codebase的易維護性。

研究表明，對于常用的編程語言，生產率似乎是固定的，但如果使用適當的高級語言，編程的生產率可以提高5倍。就拿現在還比較熱門的編程語言Python和老牌編程語言Java來說，Java是比較繁瑣的，同樣的實現一個功能，Java需要很多行代碼，但是Python可能就只要幾行就可以實現了。

這一點從下面兩個例子中就能看出：

打印Hello World

來源：51CTO博客

字符串處理

來源：51CTO博客

所以，在編程領域，高產出并不等于高價值。

2.用代碼多少來評價程序員的貢獻無疑是外行人的決定

有一個有趣的說法，程序員按字數考核算績效，是沿襲稿費制度。如果按字數結算，那就玩命灌水，如果按頁數結算，那就拼命換行。程序員績效參考稿費的結算方式，得到的結果也不過如此。

程序員的工作并不是為了敲代碼，程序員作為技術人員，編程能力、技術知識才是立足之本。代碼是智慧的產物，代碼的多寡和能實現的功能沒有直接聯系，創(chuàng)造代碼是為了提高生產效率，所以代碼的數量并不重要。

而且代碼的行數其實很容易增加，換行、初始化、賦值、添加注釋、大括號中括號小括號，或者多寫無用的類和方法，甚至可以把第三方的源碼引入到項目中。但優(yōu)質代碼是經過深思熟慮且極盡優(yōu)化的結果，其迭代過程可能數次甚至數十次，這些努力在最終代碼是看不到的。說實話，想增加行數有無數種方法。但結果是什么呢，代碼規(guī)范被破壞，而代碼質量卻難以提高。編程的本質是解決問題，而不是書寫垃圾代碼。

在網上看見一個很有意思的例子，某一位非常優(yōu)秀的程序員，別人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;
    }
}

（來源：知乎@安曉輝）

這么一看，弊端就很明顯了，很多程序員把重心放在了如何增加代碼行數上，而不是如何編寫高質量代碼上，甚至會有人不惜一切代價換取代碼量，大量復制粘貼，完全不考慮復用，從而產生大量垃圾代碼。

所以，代碼的行數并不適合作為工作量的衡量標準。

3.程序員的貢獻應從多方面來評估

一個項目麻煩的地方往往在與框架的搭建功能、需求分解功能以及后續(xù)的功能測試，代碼只占其中工作的一部分。代碼能力可以隨著經驗和時間的增多而提高，但算法邏輯能力和架構能力則不會這樣，這兩樣才是衡量程序員能力的重要標準，但這些“能力”無法計算。

所以對于程序員的績效考核，KPI標準應該復雜一些，不能單純的統計代碼行數，可以從代碼的質量，發(fā)現Bug的數量，代碼檢測結果，單元測試覆蓋度，項目中所擔任的角色和工作量等多個方面考察得出。只有多方面考察得出的結果才能更真實的反映員工的工作能力，并以此激勵程序員更加努力。

像是國內互聯網大廠騰訊的績效考核分為兩部分，業(yè)務評價和組織管理評價，通俗點說就是業(yè)績考核和行為考核，其中業(yè)績考核的權重為70%，行為考核的權重為30%。雖說網上沒有公布明確的考核標準，但是也可以看出他們的考核也是在多方位同時進行的。