他們八成是沒看過下邊這個漫畫，想靠程式碼行數來衡量也太小瞧程式設計師的創(zuo)造(bi)能力了。我建議用頭發多少或者發際線來判定，頭發多的或者發際線沒後移的都是沒努力用腦子的，都不能給高績效(開個玩笑 ).
把程式碼行數納入 KPI 一個最大的弊端就是讓很多程式設計師把重心放在了如何增加程式碼行數上，而不是如何編寫高質素程式碼上，甚至會有人不惜一切代價用作弊手段換取程式碼量，大量復制貼上，完全不考慮復用，產生大量垃圾程式碼。(很多小白程式設計師最愛復制貼上了）中國還有很多軟件公司的技術管理停留在軟件作坊的水平。
業務功能點、介面響應時間、資源占用等都可以作為量化指標衡量程式設計師的能力，但是程式碼行數不應該納入進去，有可能只會產生更多垃圾程式碼，得不償失。有點軟件工程知識的人也知道不應該根據程式碼行數，而是可讀性、可測試性、可維護性等來衡量程式碼質素，甚至現在很多時候都會想著如何精簡程式碼，減少復雜度，增加可維護性等，而不是一味地懟程式碼量。下邊這個非常有意思的漫畫很好地詮釋了程式碼行數與績效掛鉤可能會發生的一系列問題（轉載自西喬【神秘的程式設計師們】）:
