Robert C.Martin 著

第1章 專業主義

1.1 清楚你要什么

專業主義：它不但象征著榮譽與驕傲，而且明確意味著責任義務與擔當。

1.3 首先，不行損害之事

1.3.1 不要破壞軟件功能

寫一些隨時都能運行的單元測試，然后盡可能多地執行這些測試。測試覆蓋率盡可能為100%。

1.3.2 不要破壞結構

• 結構良好的代碼更靈活。以犧牲結構為代價，得不償失，將來必追悔莫及。
• 如果希望自己的軟件靈活可變，那就應該時常修改它！
• 有種策略叫“無情重構”：對每個模塊，每檢入一次代碼，就要讓它比上次檢出時變得更簡潔。每次讀代碼，都別忘了進行點滴的改善。
• 對待代碼，就如同雕塑家對待泥巴那樣，要對它進行不斷的變形與塑造。

1.4.1 了解你的領域

• 設計模式。GOF 24種。
• 設計原則。SOLID原則，組件設計原則。

1.4.3 練習

每日10分鐘卡塔。

第2章 說不

• 專業人士敢于說明真相而不屈從于權勢。
• 只有敢于說不，才能真正做成一些事情。

2.1 對抗角色

最好的結果是你和你的經理追求共同的目標。最關鍵的是要找到那個共同目標，而這往往有賴于協商。

2.2 高風險時刻

• 最要說“不”的是那些高風險的關鍵時刻。越是關鍵時刻，“不”字就越具價值。

2.4 說“是”的成本

• 有時候，獲取正確決策的唯一途徑，便是勇敢無畏地說出“不”字。

2.5 如何寫出好代碼

• 想成為風云為物或救世主有時會讓你做出一些不專業的行為
• 專業人士之所以成為英雄為物，是因為他們出色地完成了任務，不但按時而且符合預算。

第3章 說是

3.3 結論

專業人士不需要對所有請求都回答“是”。不過，他們應該努力尋找創新的方法，盡可能做到有求必應。

第4章 編碼

4.2.2 中斷

• 結對是應對中斷的一種好方法。結對搭檔能夠維護住中斷處的上下文。
• 另一種很有幫助的采用TDD。失敗的測試能幫你維護住編碼進行的上下文。

4.3 阻塞

• 創造性輸出依賴于創造性輸入。

4.4 調試

• 不管是否采納TDD或其他一些同等效果的實踐，衡量你是否是一名專業人士的一個重要方面，便是看你是否能將調試時間盡量降到最低。

4.6 進度延遲

4.6.2 盲目沖刺

• 如果經理極力要求你盡力趕上最后截止期限，那該怎么辦呢？堅決維持你的估算!
• 唯一能夠加快進度的方法便是縮減范圍。

4.6.3 加班加點

不應該采用額外加班加點的工作方案，除非以下三個條件都能滿足：

1. 你個人能擠出這些時間。
2. 短期加班，最多加班兩周。
3. 你的老板要有后備預案，以防萬一加班措施失敗了。

4.7 幫助

• 作為業傳人士，要以能夠隨時幫助別人為榮。
• 如果有人向你伸出援手，要誠摯接受，心懷感激地接受幫助并誠意合作。

第5章 測試驅動開發

5.2 TDD的三項法則

1. 在編好失敗單元測試之前，不要編寫任何產品代碼。
2. 只要有一個單元測試失敗了，就不要再寫測試代碼;無法通過編譯也是一種失敗情況。
3. 產品代碼恰好能夠讓當前失敗的單元測試成功通過即可，不要多寫。
   這兩個循環不斷反復。寫一些測試代碼，然后再寫一些產品代碼。這兩套代碼同步增長，互為補充。

5.3 TDD的優勢

5.3.3 勇氣

• 擁有一套值得依賴的測試，便可完全打消對修改代碼的全部恐懼。

5.3.4 文檔

• 單元測試即是文檔。

5.3.5 設計

• 遵循三項法則并且測試先行，便能夠產生一種驅動力，促使你做出松耦合的設計。

第6章 練習

6.2 編程柔道場

6.2.1 卡塔

• 真正的挑戰是把一個卡塔練習到爐火純青，你可窺見其中的韻律。
• some kata

http://katas.softwarecraftsmanship.org/
http://codekata.pragprog.com/

6.3 自身經驗的拓展

6.3.1 開源

• 保持不落伍的一種方法是為開源項目貢獻代碼，就像律師和醫生參加公益活動一樣。如果你是Javat程序員，請為Rails項目做點貢獻。如果你為老板寫了很多C++，可以找一個Python項目貢獻代碼。

第7章 驗收測試

7.2 驗收測試

• 我們把驗收測試定義為業務方與開發方合作編寫的測試，其目的在于確定需求已經完成。

7.2.1 完成的定義

• 應該編寫整套自動化測試，它們全都通過，就意味著滿足了所有的要求。如果對功能的驗收測試全部通過，就算真正完成了。

7.2.3 自動化

• 驗收測試都應當自動進行。在軟件開發周期中，確實有時候需要手動測試，但是驗收測試不應當手動進行，原因很簡單：要考慮成本。
• 工具：FitNesse, Cucmber, robot framework, Selenium。

7.2.5 驗收測試什么時候寫，由誰來寫

• 在理想狀態下，業務方和QA會協作編寫這些測試，程序員來檢查測試之間是否有沖突或矛盾。
• 如果只能由開發人員來寫測試，應當確保寫測試的程序員與開發所測試功能的程序員不是同一個人。
• 通常，業務分析員測試“正確路徑”，以證明功能的業務價值;QA則測試“錯誤路徑 ”、邊界條件、異常、例外情況，因為QA的職責是考慮哪些部分可能出問題。

7.2.6 開發人員的角色

• 開發人員有責任把驗收測試與系統聯系起來，然后主這些測試通過。

7.2.7 測試的協商與被動推進

• 與編寫測人協商并改進測試是開發人員的職責。絕不能被動接受測試。

7.2.8 驗收測試和單元測試

• 驗收測試不是單元測試。單元測試是程序員寫給程序唄的，它是正式的設計文檔，描述了底層結構及代碼的行為。關心單元測試的是程序員而不是業務員。
• 盡管兩者測試的可能是同一個對象，其機制和路徑卻是不同的。單元測試是系統內部進行，調用特定類的方法;驗收測試是在系統外部，通常是在API或者是UI級別進行。

7.2.10

• 請務必確保在持續集成系統中，單元測試和驗收測試每天都能運行好幾次。整套系統應該由源代碼管理系統來觸發。只要有人提交了代碼，持續集成系統就會開始構建，并運行所有的測試。
• 持續集成如果失敗了，團隊里的所有人應該停下手里的活，看看如何讓測試通過。

第8章 測試策略

8.2 自動化測試金字塔

image

第9章 時間管理

9.1 會議

9.1.4 立會

• 到場人依次回答以下3個問題：1.我昨天干了什么？2.我今天打算干什么?3.我遇到了什么問題? 每個人的發言不超過1分鐘。

9.1.7 爭論/反對

• Kent Beck：凡是不能在5分鐘內解決的爭論，都不能靠辯論解決。
• 爭論之所以要花那么多時間，是因為各方都拿不出足夠有力的證據。所以這類爭論依據的不是事實，而是信念。
• 在沒有數據的情況下，如果觀點無法在適時間(5~30分鐘)里達成一致，就永遠無法達成一致。唯一的出路是，用數據說話。
• 如果爭論必須解決，就應當要求爭論各方在5分鐘內向大家擺明問題，然后大家投票。

9.3 時間拆分和番茄工作法

• 番茄工作法的基本思想：把計時器設定到25分鐘。倒計時期間不要讓任何事情干擾你的工作。無論什么干擾，都必須等到25分鐘結束再處理。
• 一天中，不錯的情況下你可以有12_{14個番茄時間段，糟糕的情況下可能人有2}3個。把情況記錄下來并且畫圖表示，就可以很清楚地知道每天有多少時間是有效率的，有多少時間是花在雜事上的。

第10章 預估

10.1.1 承諾

承諾是必須做到的。專業開發人員不隨便承諾，除非他們確切知道可以完成。

10.2 PERT

PERT(計劃評審技術)的一部分內容就是對預估的計算方法。這種技術包含了一個非常簡單有效的辦法，把預估變成概率分布。你可以根據3個數字預計某項任務。這就是三元分析法：

• O: 樂觀預計。為保證樂觀預估有意義，這個數據對應的發生概率應當小于1%。
• N：標稱預估。這是最大概率的數字。
• P：悲觀預估。為保證悲觀預估有意義，這個數據對應的發生概率應當小于1%。
  有了以上三個預估，我們可以這樣描述概率分布：

μ = (O+4N+P)/6

μ是任務的期望完成時間。

σ = (P-O)/6

σ是這個任務概率分布的標準差，用來衡量不確定性。如果這個數字很大，就表示非常不確認。

大任務的μ 可由各小任務μ 加和得到。大任務的σ等于各小任務σ的平方和再開方。

第11章 壓力

11.1 避免壓力

• 應當避免對沒有把握能夠達成的最后期限做出承諾。
• 專業人士總會千方百計地幫助業務方找到達成目標的方法，但并不一定要接受業務方代為做出的承諾。
• 快速前進確保最后期限的方法，便是保持整潔。
• 選擇那些你在危機時間依然會遵循的紀律原則，并且在所有工作中都遵守這些紀律。

11.3 結論

• 應對壓力的訣竅在于，能回避壓力時盡可能地回避，當無法回避則則勇敢直面。可以通過慎重承諾，遵循自己的紀律原則、保護整潔等來回避壓力。直面壓力時，則要保持冷靜，與別人多多溝通，堅守自己的原則紀律，并尋求他人的幫助。

第12章 協作

12.1 程序員與人

12.1.1 程序員與雇主

• 對做的事情充滿激情是好的，但是，最好把注意力集中在付我們薪水的老板所追求的目標上。
• 專業程序員最糟糕的表現是兩耳不聞窗外事，只顧一頭將自己埋在技術堆里，甚至公司業務火燒眉毛行將崩潰了也不聞不問。
• 專業程序員會花時間去理解于業務。他們會和用戶討論他們正在使用的軟件，會和銷售人員與市場人員討論所遭遇的問題，會和經理們溝通，明確團隊的短期目標和長期目標。

12.1.2 程序員與程序員

• 專業人士結對工作，因為這是分享知識的最好途徑。專業人士不會僅憑一已之力從零開始創建知識，而是通過互相結對來學習系統的不同部分和業務。
• 結對是復查代碼最好的方式

12.3 結論

• 如果我們真想終生能以編程度日，那么，一定要學會交流。

第13章 團隊與項目

13.1.1 有凝聚的團隊

• 有凝聚力的團隊通常約有12名成員。最多可以有20人，最少可以只有3人，但是12個人是最好的。這個團隊應該程序員，測試人員和分析師，同時還要有一名項目經理。
• 程序員算一組，測試人員和分析師算一組，2:1是比較好的組合。由12個人組成的理想團隊，人員配備情況是這樣的：7名程序員，2名測試人員，2名分析師和1名項目經理。

13.2 結論

• 團隊比項目更難構建。困此，組建穩健的團隊，讓團隊在一個又一個項目中整體移動共同工作是較好的做法。團隊也可以同時承接多個項目。在組建團隊時，要給予團隊充足的時間，讓他們形成凝聚力，一直共同工作，成為不斷交付項目的強大引擎。

第14章 輔導、學徒期與技藝

• 學校能夠傳授的是計算機編程的理論。但是學校并不會也無法傳授作為一名編程匠者所需掌握的原則，實踐和技能。這些東西只有經由師徒個體間多年的細心監督和輔導才能獲得。
• 對新人的培養的輔導非常重要
• 學徒/實習生-->熟練工(5年左右)-->大師(10年以上)。大師就像星際迷航中的Scotty。