每次我們 GitHub 提交的時候都能看到有多少行代碼的增加和減少，那麼對於一個程序而言，尤其是作為對一個大型項目的 Commit 而言，代碼越多就越 NB 嘛？還是反之，越少越好呢？
在 近兩萬名開發者維護的 Linux 內核代碼行數已超 2500 萬中，我們發現：
再看今年的數據，到目前為止，今年已有 49,647 次提交，增加了 2,229,836 行代碼，同時刪除了 2,004,759 行代碼。所以淨增加 225,077 行代碼。還值得關注的是，Linux 內核今年刪除了一些對舊的 CPU 架構支持和內核中的其他代碼，所以在添加了許多新功能的同時，由於進行了一些清理，內核並沒有像人們預期的那樣膨脹。
可見，在大型軟件的開發過程中，並不是每次都有代碼量的大量增加才表示一個軟件正在健康發展，除了對於功能的更新以外，我們也需要對一些已有代碼進行重構和重寫，增加整個 Codebase 的易維護性。
新增代碼沒啥可驕傲的，敢刪除代碼才驕傲
那麼對於一家公司而言，或者對於許多比較傳統的企業來說，單純通過對於員工代碼量的統計來計算 KPI 是否合理呢？讓我們來看看網友的看法：
這年頭仍然還是大量的公司以代碼量來考核KPI。代碼行數說明不了什麼問題，而且當以代碼行數來考核KPI時，會引起一些其它的副作用。我的一個學生，學得相當不錯，很有悟性。他前段時間跟我說，他這個月KPI又不合格，因為代碼量為0，原因是他接手的這個項目發現了很多廢物代碼，他每見到一處就重構一次。最後到月底考核時，代碼量為負數了。那麼很明顯，1W行代碼在5000行就能解決的，卻因為這樣的考核變成最後代碼寫成1.5W行。這樣的考核決策顯得完全沒有任何意義。
的確，除了在初創階段，代碼量（或者說：代碼行數的增量）對於衡量一個程序員的業績沒有什麼太大幫助，在代碼體積提升的階段不注重維護和重構，只會帶來一些意想不到的問題。
除了代碼量以外，我們在《人月神話》中可以知道：
- 對於常用的編程語言，生產率似乎是固定的
- 使用適當的高級語言，編程的生產率可以提高5倍
如果你所在的企業/小組比較開明，對於低效率的代碼使用其他語言重寫可能會帶來良好的影響力，從而在只編寫少量代碼的情況下獲得整體軟件質的提升。當然，如果你所在的公司沒有那麼開明的話，還是需要注意一下的，不然容易發生下圖所描述的情況：
所以，代碼越多越 NB 嘛？不見得，一個 50 行可以搞定的 feature 為了提升 KPI 而強行寫了 150 行只會讓代碼變得不好用不好讀，搬起的石頭最終還是要砸到自己（或者下一個接盤的人）的腳上；
那代碼越少就越 NB 嘛？其實這裡要加入兩個前提，如果你寫的代碼量很少，且：
- 完成了應有的功能
- 方便維護，結構明確（而不是 Code Jam）
那麼，這個代碼必然是單純 "湊字數" 寫出來的要好很多，也更加能體現對應的程序員對於程序的把握能力。
互動話題：
作為程序員，你認為以代碼量考核是否合理？自己公司的情況是什麼樣的？程序員的 KPI 應該是什麼？可在評論區留言哦～
閱讀更多 力扣LeetCode 的文章
