對于特定的人，在大致時間段里他所能寫的、確定質(zhì)量的代碼基本上應(yīng)該是個確定值。

這點(diǎn)似乎顯而易見，但事實(shí)上大多時候卻總是被忽視。

如果項(xiàng)目負(fù)責(zé)人總是認(rèn)可上面的基本點(diǎn)，那么任何項(xiàng)目的日程就應(yīng)該以此為前提，而不是以此為變量。

假設(shè)說一個項(xiàng)目被估計(jì)為1萬行(SLOC)，團(tuán)隊(duì)平均每人每天可以寫100行代碼，如果團(tuán)隊(duì)中有5個人，那么就應(yīng)該至少為編碼保留20整天。

說到這里，為避免誤解，要區(qū)分一下編碼速度和生產(chǎn)率這兩個概念。

項(xiàng)目管理中常用的一個數(shù)據(jù)被稱為生產(chǎn)率，用代碼行計(jì)算時，會被表示為SLOC/MM。

這個值用于表示平均每人月的代碼產(chǎn)出。

其基本算法是規(guī)模除以項(xiàng)目所用的人月，而項(xiàng)目所用的人月中包含了設(shè)計(jì)、測試、修Bug等時間，至于包不包含需求、管理等的時間往往因人而異。

這個值有意義，但受項(xiàng)目時間分配比率影響較大，浮動空間也大。

而編碼速度單純指個人為編寫完成某個功能（經(jīng)過自己的測試），而每天寫的代碼。

這時代碼中一定是有Bug的，所以這個值仍然有浮動空間，但已經(jīng)可以收的很窄，并且在短期內(nèi)不太可能發(fā)生太大的變化。

所以這個值應(yīng)該更有意義。

我試圖調(diào)查編碼速度，但實(shí)在找不到什么資料。眼下可以做到的是：

通過找到生產(chǎn)率的數(shù)據(jù)，假設(shè)編碼的時間為1/3，這樣可以概算出一份編碼速度的值。

找到一份不同語言間的比例值。

定性分析一下一般的情形。一般的情形是指：沒有太難的待研究課題，比如排序算法速度優(yōu)化20%，大致知道怎么完成既定功能的情形。

下面是上述總結(jié)和分析的結(jié)果，希望有人愿意分享更多信息，也把這個數(shù)據(jù)做的更精確點(diǎn)。

按照生產(chǎn)率概算的編碼速度

（生產(chǎn)率數(shù)據(jù)來自《軟件估算--黑匣子揭秘》，概算的數(shù)據(jù)是我算的，我也找不到編碼的語言究竟是什么，Sorry。）

 不同語言間的比例值

（這個比例值用來描述，不同語言的等價性，數(shù)據(jù)源同上）

假如這是真的，那么用后面三種語言，編碼速度會提高2.5倍。我自身對此表示懷疑，至少C++，C#以及Java應(yīng)該是不同的，但數(shù)據(jù)確實(shí)沒摘錄錯。

定性分析

為了做定性分析需要假設(shè)一些前提：

• 沒有特別的難題（比如：優(yōu)化性能，API文檔不全，也要排除研究型項(xiàng)目）。
• 不用拷貝粘貼大法。
• 去除項(xiàng)目交流，會議等，每天有6個小時可以全身心寫程序。
• 假設(shè)主要語言是C/C++，C#，Java。

如果我們進(jìn)一步假設(shè)，上限是1分鐘可以寫一行程序，那么編碼速度的上限值是：360SLOC/天。

如果我們認(rèn)為編碼速度有10倍差異，那么下限值是36SLOC/天。

也就是說編碼速度的區(qū)間是36~360SLOC/天。

從我個人的角度看，我感覺這個范圍是可用的，360SLOC/天絕對是個上限值。所以我個人是不相信上述表中超過360部分的數(shù)字的，除非把html也算進(jìn)來。

PS:干這事的一個感覺：

這活太費(fèi)勁，越做感覺要做的事越多。

我對上述摘錄的有些數(shù)據(jù)很是有些懷疑，但也找不大更合適的數(shù)據(jù)來反駁。比如：C#和C++的比例不應(yīng)該是1:1啊。

這事實(shí)在應(yīng)該科研機(jī)構(gòu)或者大學(xué)干，但又找不到國內(nèi)那個機(jī)構(gòu)或?qū)W校干了這事，這是軟實(shí)力啊。

自己這個算拋磚引玉吧，有對***個表格進(jìn)行補(bǔ)充的數(shù)據(jù)的話，可以直接回下。

【編輯推薦】

1. 編碼20年的老程序員分享所積累的20條編程經(jīng)驗(yàn)
2. 程序員應(yīng)該讀的故事：三個事和三個問題
3. 海軍陸戰(zhàn)隊(duì)退役兵：我是如何12周零基礎(chǔ)變身程序員
4. 程序員們 不要想一輩子靠技術(shù)混飯吃
5. 不要自稱為程序員