（轉載）敏捷開發一千零一問系列之三十三：天天編碼多少行？

（轉載） http://blog.csdn.net/cheny_com/article/details/8786595

這是敏捷開發一千零一問系列的第三十三篇。（在這裏提問，之一，之二，之三，問題總目錄）

 

原問題來自http://blog.csdn.net/cheny_com/article/details/6594507#comments六樓，經讀者贊成，摘錄以下：

 

「通常而言，大體天天高手能編寫100多行有效代碼（按分號計數），新手會多一些但也不超過200（他們編寫代碼比較費）。」 從全年平均來講，這個數據是否是有點大？記得在你的哪篇博客裏有提到，你說過你工做的4-5年間，僅寫了2萬行代碼而已——平均一天不到20行啊。我之前一直認爲日均100行大概是一個主流行情，我所經歷的項目大概是這個水平，那是由於咱們項目是從零作起，並且界面較多，編碼難度不大（但業務難度較大）。最近咱們的項目要產品化，修修補補了一年多，忽然發現，即便對咱們的軟件，也確定不到日均100行啊。大部分時間在調試；改BUG；因需求調整，而作一些修改（修改人可能和開發者不是同一我的了），這時對原來代碼有一個從新學習的過程（就是捋一遍）。------- 這實際上是代碼質量差的表現之一。因此我愈來愈想在項目中引入結對編程，以此提升質量，減小返工和從新學習代碼所須要的時間。

（結對編程）你以爲可行嗎？

答（原答案有擴充）

 

原問題實際上分爲兩個部分，但都與編碼速度有關。分別回答。

關於編碼速度

 

大體的編碼速度

 

「高手天天100行」是編碼階段的速度，也就是若是今天這我的在編碼，那麼差很少能出來100行。平均到全生命週期，好比每一年，大約是40～50行（這個也偏高，等等說）。我我的在以前說的那個團隊的工做中只有一半時間在編程，還有不少時間作別的。一個是數字電視的安全協議構建+IC卡外協之類的工做，另一個是穿插到別的子團隊幫別人作設計（這個能夠說是鬆結對的來源）。

補充：我在2002年左右精確計數了一個項目的開發過程，是一個小瀑布模型，編碼期27天日均編碼108行，整個週期日均編碼46行。兩年前開始的火星人項目，編碼時的日均編碼速度也是100行左右。不事後來有了L型代碼結構，編碼速度明顯降低了，一週可能只編寫100～200行代碼，多數時間用在界面設計上。這不是說「設計時間長了，編碼時間短了」，而是說L型代碼結構主要是代碼裝配過程，效率極高，所以「不太須要長時間編碼」。

爲什麼精簡的代碼速度更高

 

國外業界有一個說法：不管採用何種語言，編碼的速度基本相同。好比若是用匯編，一天100行，那麼用C++，也差很少是100行。所以，越高級的語言，越能節省代碼。

另一個則是：越精簡的語言，越能節省代碼，包括同一種語言。神奇的是，高手用精簡的語言編寫代碼也能一天編寫100行；而新手乍看能用1000行爛代碼實現相同功能，並且時間也是一天。差異究竟是什麼呢？

首先，高手和而不一樣，新手同而不和。

若是10個高手看另一個高手的100行代碼，會說：「恩，差很少，讓我作也差很少這個樣子」。錯誤實現的路徑不少，正確實現的路徑至關有限。即便存在少許多個最佳實現，多數高手在採納其中一個的同時，也曾經思考過別的方法。10個新手看另一個新手的1000行代碼，就不那麼容易了。咱們想象中的「冗長但容易理解的代碼」，實際上是對編寫者而言的，旁觀者其實很難看懂。我見過一個有44個return總長度550行的函數，最後總算變成110行，只有不到10個return了（多數都在函數開頭）；另一個則是4000行代碼65個函數，被改爲2個函數，加在一塊兒不到55行。這些狀況下，不管高手或新手都會認同後者更容易閱讀和理解，實際上連原編寫者寫完後也有同感。而冗長代碼別說新手能不能看懂，高手也得看一陣子才明白。

其次，精簡的代碼中有正代碼，冗長的代碼中有負代碼。

爲了精簡代碼，不免會用到類、函數、泛型這類封裝。這些封裝不但如今會用到，將來也會重用，從而大大節省將來的編碼量——或者說將來編碼速度不會有提升，甚至有降低，但功能產生的速度反而提升了（這正是以前提到的「火星人」中L型代碼結構的現狀）。除了重用產生的編程速度以外，因爲重用的質量高於新代碼（有前提但可實現），因此還節省了測試時間。

而冗長代碼則有「負代碼」。在圍棋裏邊有個術語叫作「負目」，就是若是有一塊孤棋，對方可能經過攻擊而得利，那麼在計算其所圍面積的時候，要保守一些甚至減掉一些。冗長代碼也是如此。不管是測試、嘗試複用、修改需求、修改設計、修改其中的缺陷、轉交給他人維護，冗長代碼都會在將來產生額外的工做量。

再次，邀請新手向高手靠攏是一種正能量，而要求高手向新手妥協是一種負能量。

這也是本人爲什麼極力推崇鬆結對編程和139團隊的緣由，一個團隊的最佳狀態顯然是：編寫高質量代碼 + 高手幫助新手理解和編寫高質量代碼。咱們當年那個25我的的團隊在短短半年左右就差很少作到了這一點，而團隊的多數人工做經驗都小於4年（本人當時6年，是長的）。

因此不須要也不該該對中間狀態有任何幻想和耐心。

 

關於編碼的質量要求與編碼速度的關係

 

感受結對編程可行（不過推薦鬆結對），不太重構後的產品的函數、類必定要短、小，嵌套層數能夠多一些。這樣的好處是之後若是又要重構，多數狀況下都不須要動每一個函數，只要重構某些便可。
對質量而言，應該高到不會有明顯在「改Bug」的時期，應該每一個人回憶起來，除了幹別的就是編碼，不多能記起某段時間在調試Bug。這樣編碼速度和編碼佔整個時間的比例就會更高。反正你統計一下就可能發現：高手能夠一天100行，平均到一年是50行；而新手可能一天1000行，平均到一年卻不是100行，而是更少，由於有不少時間在改Bug。這種狀態下，不如讓他們跟着高手先精心寫好一些代碼，再繼續前進，不然累死。