《構建之法》一書已完成了第一遍的閱讀，接下來，我將隨機抽取其中的一段進行精讀。

移山公司的項目進行了一段時間，TFS上也積累了不少數據。大栓做了“數據挖掘”，整理出來一些統計信息，向各位領導匯報。

大牛：哇！前端組的這位開發人員是冠軍呀，他導致的Bug總量約等於所有其他成員的總和。

二柱：那是有客觀原因的，你可能不知道他的工作量是最大的。

大牛：那也不能因此產生這麽多Bug，而讓整個團隊的進度停下來吧。

二柱：別人工作得這麽辛苦，我倒是不太忍心再批評他。阿超，其實我覺得我們應該鼓勵成員多做貢獻，錯誤總是難免的，但是你知道他上星期完成了兩個功能，明顯比別人快多了。別的同事和他一比，就慢多了。

大牛：我不太同意，從TFS的數據來看，他的Bug數量遠比別人多，而且不少Bug都有一段時間了，你說的“慢”的人，好像沒有多少Bug，也是差不多按期完成的。問題是你希望團隊成員是“蘿蔔快了不洗泥”型的，還是“慢工出細活”型的？

阿超：我有一個故事，假設團隊裏來了兩位年輕人，嗯，就叫“蘿蔔”和“白菜”。蘿蔔做事很快，是“蘿蔔快了不洗泥”類型；白菜是“慢工出細活”類型。分配了任務後，蘿蔔很快就說做好了！白菜還在吭哧吭哧地跟項目經理和測試人員討論。領導很高興，讓蘿蔔去做更多的事。開發階段結束了，蘿蔔比白菜多做了不少功能。穩定階段開始了。大家發現蘿蔔負責的功能出了很多問題，白菜的模塊倒是比較穩定。然而蘿蔔在團隊中的曝光率很高，很多問題都在等著他解決，從統計數據上看，他也修復了不少小強。白菜搞定了自己負責的模塊，開始幫助其他人，由於不熟悉其他人的模塊，白菜修復的缺陷不多。由於蘿蔔的設計有缺陷，導致模塊非常復雜，蘿蔔也成了唯一了解其模塊的開發人員。項目最後階段，幾乎都是蘿蔔工作得最晚，把最後幾個缺陷給修復了。領導們說：有問題，找蘿蔔！項目結束了，開始了績效考核，領導A認為白菜績效不錯，模塊按時完成，沒有大多問題，然後還能幫助其他成員；領導B認為蘿蔔是超級明星：第一個完成模塊，修復的缺陷最多，而且掌握了最復雜的模塊，離開他不行，工作得也很晚，有突出貢獻。至於白菜，領導B沒感覺他做了啥，僅僅是按要求完成任務了。蘿蔔白菜，各有所愛。那蘿蔔和白菜誰該得到獎勵，誰該得到批評呢？假如領導B的評價方式占了上風，蘿蔔得到獎勵，白菜離開了團隊，你覺得下一個版本會出現什麽情況？

大牛：我估計蘿蔔會成為“構建大師”，每天忙得不可開交。然而項目進展不一定會像以前那樣順利……

二柱：有人會懷念白菜。

大牛：你的意思是團隊的領導者文化決定了團隊的風格。但是當前該怎麽辦呢？阿超：所以我們要讓“蘿蔔快了不洗泥”的人慢下來，這樣能減少他們的危害。大牛：授予他們“蘿蔔大師”的稱號？

阿超：恐怕不行，我們要胡蘿蔔和大棒並用。我們的大棒就是“小強地獄”（Bug Hell）。

這麽一個故事，充分體現了軟件開發過程中的“質”與“量”不易兼顧的問題，過於追求“量”，會導致BUG偏多，模塊可讀性不高，影響整體團隊進度等問題；同樣地，過於追求“質”，則會在修復BUG上花費較多時間，一樣會影響整體的團隊進度。但是相比而言，過於追求“量”的情況更多，危害也更大，因此，對這一情況加以限制也顯得非常重要。而《構建之法》書中給出的方法便是“小強地獄”，即讓導致BUG數量超標者進入小強地獄，期間只允許修復BUG，不允許參與其他開發工作，直到其導致的BUG數量低於閾值為止。這樣的方法，只要閾值設置得合理，就可以很有效地使團隊成員自覺把控“質”與“量”之間的平衡，從而提升整體團隊的工作效率。

構建之法閱讀隨筆一