程序员每天到底可以写几行代码？
對于特定的人，在大致時間段里他所能寫的、確定質(zhì)量的代碼基本上應該是個確定值。
這點似乎顯而易見，但事實上大多時候卻總是被忽視。
如果項目負責人總是認可上面的基本點，那么任何項目的日程就應該以此為前提，而不是以此為變量。
假設說一個項目被估計為1萬行(SLOC)，團隊平均每人每天可以寫100行代碼，如果團隊中有5個人，那么就應該至少為編碼保留20整天。
?
說到這里，為避免誤解，要區(qū)分一下編碼速度和生產(chǎn)率這兩個概念。
項目管理中常用的一個數(shù)據(jù)被稱為生產(chǎn)率，用代碼行計算時，會被表示為SLOC/MM。
這個值用于表示平均每人月的代碼產(chǎn)出。
其基本算法是規(guī)模除以項目所用的人月，而項目所用的人月中包含了設計、測試、修Bug等時間，至于包不包含需求、管理等的時間往往因人而異。
這個值有意義，但受項目時間分配比率影響較大，浮動空間也大。
?
而編碼速度單純指個人為編寫完成某個功能（經(jīng)過自己的測試），而每天寫的代碼。
這時代碼中一定是有Bug的，所以這個值仍然有浮動空間，但已經(jīng)可以收的很窄，并且在短期內(nèi)不太可能發(fā)生太大的變化。
所以這個值應該更有意義。
我試圖調(diào)查編碼速度，但實在找不到什么資料。眼下可以做到的是：
- 通過找到生產(chǎn)率的數(shù)據(jù)，假設編碼的時間為1/3，這樣可以概算出一份編碼速度的值。
- 找到一份不同語言間的比例值。
- 定性分析一下一般的情形。一般的情形是指：沒有太難的待研究課題，比如排序算法速度優(yōu)化20%，大致知道怎么完成既定功能的情形。
下面是上述總結和分析的結果，希望有人愿意分享更多信息，也把這個數(shù)據(jù)做的更精確點。
?
按照生產(chǎn)率概算的編碼速度
（生產(chǎn)率數(shù)據(jù)來自《軟件估算--黑匣子揭秘》，概算的數(shù)據(jù)是我算的，我也找不到編碼的語言究竟是什么，Sorry。）
| 代碼行/天?最低值-最高值（典型值） | |||
| 軟件類型 | 10,000代碼行的項目 | 100,000代碼行的項目 | 250,000代碼行的項目 |
| 航空電子 | 15-150(30) | 3-45(7) | 3-30(6) |
| 應用系統(tǒng) | 120-2,700(450) | 30-1050(90) | 15-750(75) |
| 命令與控制 | 30-450(75) | 7-90(15) | 6-75(12) |
| 嵌入式系統(tǒng) | 15-300(45) | 4.5-75(11) | 3-60(9) |
| 公眾因特網(wǎng) 系統(tǒng) | 90-1500(225) | 15-300(45) | 15-225(30) |
| 內(nèi)部內(nèi)聯(lián)網(wǎng) 系統(tǒng) | 225-2700(600) | 45-1050(120) | 30-750(90) |
| 微代碼 | 15-120（30） | 3-30（6） | 3-15（4） |
| 過程控制 | 75-750(150) | 15-150(45) | 13-130(30) |
| 實時系統(tǒng) | 15-225(30) | 3-45(7) | 3-45(6) |
| 科學系統(tǒng)/ 工程研究 | 75-1125(150) | 15-225(45) | 12-150(30) |
| 套裝軟件 | 60-750(150) | 15-150(30) | 10-120(30) |
| 系統(tǒng)軟件/ 驅(qū)動程序 | 30-750(90) | 7-150(15) | 6-120(13) |
| 電信軟件 | 30-450(90) | 7-90(15) | 6-75(7) |
?
?
不同語言間的比例值
（這個比例值用來描述，不同語言的等價性，數(shù)據(jù)源同上）
| 語言 | 與C語言語句數(shù)量比 |
| C | 1 |
| C++ | 2.5 |
| Java | 2.5 |
| C# | 2.5 |
?
???假如這是真的，那么用后面三種語言，編碼速度會提高2.5倍。我自身對此表示懷疑，至少C++，C#以及Java應該是不同的，但數(shù)據(jù)確實沒摘錄錯。
?
定性分析
為了做定性分析需要假設一些前提：
- 沒有特別的難題（比如：優(yōu)化性能，API文檔不全，也要排除研究型項目）。
- 不用拷貝粘貼大法。
- 去除項目交流，會議等，每天有6個小時可以全身心寫程序。
- 假設主要語言是C/C++，C#，Java。
如果我們進一步假設，上限是1分鐘可以寫一行程序，那么編碼速度的上限值是：360SLOC/天。
如果我們認為編碼速度有10倍差異，那么下限值是36SLOC/天。
?
也就是說編碼速度的區(qū)間是36~360SLOC/天。
從我個人的角度看，我感覺這個范圍是可用的，360SLOC/天絕對是個上限值。所以我個人是不相信上述表中超過360部分的數(shù)字的，除非把html也算進來。
?
PS:干這事的一個感覺：
這活太費勁，越做感覺要做的事越多。
我對上述摘錄的有些數(shù)據(jù)很是有些懷疑，但也找不大更合適的數(shù)據(jù)來反駁。比如：C#和C++的比例不應該是1:1啊。
這事實在應該科研機構或者大學干，但又找不到國內(nèi)那個機構或?qū)W校干了這事，這是軟實力啊。
自己這個算拋磚引玉吧，有對第一個表格進行補充的數(shù)據(jù)的話，可以直接回下。
補充一點：
看了些評論，發(fā)現(xiàn)很多人在說代碼行不好的地方，這個反倒是不用講的。
因為代碼行不好的地方確實如大家所說，甚至更多。
任何一種度量方法必然有其限度，超過即是錯誤。
關鍵是當事人要把握數(shù)據(jù)究竟應該怎么用。
好比說用代碼行度量個人不太行，但完全不度量同樣也是不行。
轉(zhuǎn)載于:https://www.cnblogs.com/xiaowangba/archive/2012/12/11/6314391.html
總結
以上是生活随笔為你收集整理的程序员每天到底可以写几行代码？的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 披星“戴”云，百治百效
- 下一篇： centos 6.3 x86_64安装3