學習、紀律與交流——《Clean Coder》讀後感

　　看Bob大叔的書，還要追溯到《敏捷軟體開發——原則、模式與實踐》。這是一本改變我對軟體看法的書，也使得我徹底擺脫了一個純編碼者的思維，繼而轉向以研究設計架構、分析使用者需求為中心的軟體開發方式，可謂一部有重要影響力的書。這個以後會有專文描述，在此不贅述啦。

　　其後看了《Clean Code》（乾淨程式碼），此書可以認為是敏捷軟體開發一書的具體化。那本以思想為主，這本以程式碼細節為主。看完之後對自己編碼質量的要求又更進了一步。可以說是開啟了激發了我精進程式碼質量的動力。

　　這次看到這本雖然正文加附錄僅僅二百零四頁的《Clean Coder》（乾淨編碼者——專業級程式設計師編碼法典）， 心裡異常激動，前兩本如果說側重點還偏於原理和技術的話，這一本從名字上看，就是偏重人的。本來想翻譯一下給朋友看，後來發現國內的出版社有出版計劃，我 就決定先看完英文版，等中文版出來再和朋友們一起討論、學習。讀書的時候做了很長的筆記，如果全寫出來，恐怕抓不住重點。這裡就根據幾條主要的線索把一些 重要的問題整理出來，以輔助大家閱讀和理解此書。

　　全書僅僅十四章。我自己是在順序閱讀中，是沿著三大主線進行思考的：學習、紀律、交流。

　　前三章可以作為一組，從“職業精神、學會拒絕、學會承諾”三個切入點，講述了作為一個職業程式設計師，要學會從工作經驗中學習為人處世之道。具體說來，要 會依據一些周圍的情勢、同事的語氣、自己的能力與時間安排等因素，決定是應該拒絕一個新功能的加入還是應該承諾在一個給定的時間內按時交付它。我在學會拒 絕和承諾新需求的方面，一直做的很不到位。看了此書我才發現，要根據整個工程所處的狀態，向隊友陳述工程的實際情況。只有大家瞭解了實際情況，才能作出一 個建設性的答案，以決定一個新功能是應該在下一版在做，還是應該加班做好，抑或採用一些臨時方案先使它上線。關於工程進度，表面的和諧和不夠深入的交流， 都是導致工程延期的重要因素。

　　中間六章可以作為一組，從“編碼、測試驅動開發、例行程式碼功力訓練、驗收測試、測試策略、時間管理”等六個方面講述了一個專業程式設計師（即本書標題所謂的“乾淨編碼者”）所應具有的工作行為準則。

　　在編碼這章中，作者講述了專注編碼的重要性。同時也強調了過於專注，而不時時用程式碼審查或測試用例來輔助督促程式碼質量的話，也會導致程式碼細節美麗但是大方向走偏。編碼應當是短時間，高效率的作業，如果思維受到阻滯，應當及時放鬆，不能強求。

　　第五章講述了測試驅動開發（TDD）的好處，這可以認為是一個介紹性的文字。TDD新手要入門的話，推薦Kent Beck的《測試驅動開發》一書。關於TDD，一些網友以及我都曾表示過，它不宜被無條件的套用。其實TDD的核心意圖，還是為了以測試用例保證程式碼質量，同時以測試用例作為需求文 檔規格書（這一點我原來未能認識到，本書第七章明確提及）。只要把握住這一點，在具體的實踐中，可以對測試策略進行靈活調整。（參看拙作：測試驅動開發到底好不好）

　　第六章講到了一些例行的程式碼功力訓練。的確，作為一個技術行業，長時間脫離編碼實踐是不行的。即便有朋友進入了管理層，我也還是堅持建議大家應該做例 行的程式碼訓練。書中推薦設定一個“程式碼道場”做練習環境，通過“形”（單人程式碼練習，推薦Bob大叔在《敏捷軟體開發》中所舉保齡球的例子）、“技”（雙 人結對編碼練習）、“自由格鬥”（多人輪流程式碼訓練）來進行例行練功。我認為具體形式上可以不必拘泥，但是每隔固定時間，如一週左右，應該針對一些小問 題，比如排序、搜尋、小應用、小遊戲等，進行程式碼訓練，其實也是一個將軟體設計思路通過程式碼練習凝固的過程。

　　第七章講了驗收測試的重要性。業務和技術人員通常會對一個需求的描述與實現進度產生理解分歧，以致交付的產品未能滿足客戶需求。這就需要雙方用驗收測 試來消除對於需求描述和進度所產生的歧義。由於GUI測試的易變性，針對GUI的測試應當儘可能的少。首先應將GUI下面的業務規則測試和GUI測試本身 分離，這一點很多同學都沒能做到。其次，針對GUI自身的繪製邏輯與客戶響應進行測試，底層業務邏輯可以用空實現程式碼填充。

　　第八章說，專業級程式設計師應該及時發現產品問題，而不是一味推給QA（質保人員）。程式、QA、商務應當合作。在驗收測試中，QA測試極端路徑，商務測 試（或通過程式設計師測試）正常路徑，兩者互補。在作者構想的“測試金字塔”中，單元測試覆蓋率應接近100%，針對API的元件測試應占50%，同樣針對 API的整合測試應占20%，主要針對GUI的系統測試應占10%，為了探究系統執行特性所寫的探索測試應占5%。

　　第九章講時間管理。不能快速解決的爭議，一定是雙方論點均有立足點的議題，此時不應浪費過多時間爭論，而應拿出資料，用理性說話。其後講到用番茄法進 行時間管理的一些竅門。最後提及一個重要問題：如果發現當前工程的發展方向已經無法靈活滿足需求，則應及時重構甚至重新設計，否則將來等缺陷積累到一定時 點，必將花費更多時間去返工。此一點可謂切中要害，希望大家牢記在心，不要因為對工程缺陷一時的放縱而導致大方向走偏。

　　最後五章可作為第三部分，主要講述了“工程估算”，“應對壓力”，“協同工作”，“團隊與工程”，“督導、學徒制與程式碼技藝”等五大涉及交流的問題。

　　PERT估演算法是應重點掌握的知識。在估算中，針對某一任務在“一般情境”（相對於最壞情境和最好情境）下所需時間的估量，可以通過寬頻預測法及其變體（Flying Fingers, Planning Poker, Affinity Estimation等）來討論出共識。大數法則對於估量大型任務很有幫助。

　　應對壓力一章得出的結論是，在重重壓力下，保持工程乾淨，不走樣的唯一辦法，就是堅持自己知道的且真正管用的工作守則，還應注意保持冷靜，溝通，及時尋求幫助。

　　協同工作一章講述了程式碼評審：系統絕不應含有未被評審的程式碼。程式碼評審有很多種方式，它們大多極端低效。最優效率的、最有用的方式就是一起寫程式碼（即 結對程式設計，一人寫程式碼，另一人當場評審，過一定的時間二人交換）。還講了專業程式設計師互相交流的方式：他們能互相感知對方的恐懼；能不經意地聽到某人沮喪的 牢騷；時而不時的交流一下子，要有通過說話進行的交流，也要有通過肢體語言進行的；要做為團隊的一份子去交流。

　　團隊與工程一章，作者提出了自己構想的一個優化配置過的團隊模型（我稱之為“勝利十二人”）：七個程式設計師，兩個測試，兩個系統分析員，一個專案經理。 更重要的是，明確論證了一個結論：要先建立有凝聚力的團隊，此後才能將工程根據團隊成員的特性分配給他們。針對團隊的培養才是使得工作能夠高效、可持續進 行的一條正道。

　　最後一章中，作者通過與醫療行業的類比，建議公司都應設立針對軟體開發者所進行的合理培訓期與督導實習制度。這個我想很多國內工作環境未必能保證。接 下來作者構想了一個用“大師——熟練工——學徒工”三階段來指示軟體開發者職業生涯的路線圖。軟體高手（大師）應當擁有至少10年工作經驗，能夠堅守自己 的技術角色而不醉心於管理職位；熟練工應具備五年工作經驗（原來我同事小利和小愛本人都可算熟練工，小小的自滿一把，嘿嘿），他們專精於一門語言，一個系 統和一個平臺，但是願意學習更多知識。他們中的高水平者可不需大師監督自行做軟體，初級水平者尚需高手監督與程式碼審查。熟練工之間應互相審查程式碼；學徒工/實習生則必須在熟練工的帶領下做事，且至少一年。作者說現實中的公司和這個設想制度的主要差別即是缺乏老手教導新手的責任觀。

　　文末作者總結了程式碼工匠和程式碼技藝的定義：程式碼工匠掌握了技巧和質量。其工作快速而不忙亂。提供合理的工期估量，按時交付。知道何時該拒絕，但也會努 力去完成力所能及的任務。一個程式碼工匠必是一個專業人員。程式碼技藝是程式碼工匠所具有的意識。是一種包含價值觀、原則、技術、態度與問題解決辦法的文化基 因。同時作者作出了呼籲：要勸說他人接受程式碼技藝的思維模式，首先自己要作為一個行為榜樣，成為一個程式碼工匠，將程式碼技藝展示出來，這樣文化基因自然就會 發生作用。在軟體行業的我們應當面對現實，教導下一批軟體開發者直至其成熟。這個責任落在我們的身上，而不是大學的身上。

　　很少有書的附錄能像本書這麼有內容。除了一些頗為有用的工具介紹之外，還告訴我們，一個工程的待做任務與Bug不能積累太多，否則“事務追蹤”便失去其“追蹤”的意義了。還強調了測試用例之間不能有依賴性。這是個大問題，可以參考《xUnit Test Patterns》 一書。作者還提及，程式設計要解決的問題不在程式碼，而在細節，UML等模型驅動架構（MDA）無法將細節徹底從程式碼中剝離，因而無法成功。實際上也不可能剝 離。將來即便有成功的MDA，也是來自程式設計師而非架構師，他們將會把UML轉變成一種新的能夠描述細節的程式設計序語言。這一點我本人不太理解和贊同，希望與 大方之家討論。

　　縱觀全書，很少有一本著作能夠教給我們這麼多有關軟體設計行業的心得體會。這些心得還需隨著實踐去加深和調整。一個專家級程式設計師，必然是不停地從工作經驗中學習，在工作中堅守行業質量準則，並且願意與工作夥伴密切交流的人。

　　本文為原創，如需轉載請聯絡作者（Email eastarstormlee@gmail.com 微博 http://weibo.com/eastarlee）