作者：[美] Robert C. Martin
翻譯：章顯洲 余晟
https://book.douban.com/subject/11614538/

第一章 專業(yè)主義

1.1 清楚你要什么

專業(yè)主義的精髓在于將公司利益視同個人利益。所以犯錯不是“在所難免的”，而是應(yīng)當(dāng)極力避免，并勇于承擔(dān)后果。

1.2 擔(dān)當(dāng)責(zé)任

1.3 不行損害之事

1. 不破壞軟件功能
   讓QA找不出問題，而不是讓QA幫忙檢查
2. 確信代碼能正常運行
   要考慮單元測試，測試覆蓋率，測試驅(qū)動開發(fā)（TDD）
3. 自動化QA
4. 不破壞結(jié)構(gòu)
   所有軟件項目的根本指導(dǎo)原則是：軟件要易于修改。
   不破壞結(jié)構(gòu)并不表示盡量少修改代碼，相反，如果期望自己的軟件靈活可變，就應(yīng)該時常修改它。
   事實是，大多數(shù)開發(fā)人員不敢不斷修改代碼，因為害怕改壞了。這里就又回到上面的“自動化測試”，如果有自動化測試，并且測試覆蓋率也很高，那么就不會害怕改壞了。

1.4 職業(yè)道德

職業(yè)發(fā)展是個人的事情，雇主沒有義務(wù)考慮這些，也沒有義務(wù)給你培訓(xùn)，送你參加會議等等。

職業(yè)道德是：

1. 你自己要計劃每周工作的時間，比如60小時，其中40小時是給雇主的，剩下的20小時是給自己做提升使用。
2. 了解你的領(lǐng)域
   工作中涉及到的東西都要去了解，否則只能寫寫 if-else, while 之類的代碼了。

以下是每個專業(yè)軟件開發(fā)人員必須精通的事項：
設(shè)計模式：GoF 書中（設(shè)計模式）的23種模式
設(shè)計原則：必須了解SOLID原則，而且要深刻理解組件設(shè)計原則
方法：XP、Scrum、精益、看板、瀑布、結(jié)構(gòu)化分析、結(jié)構(gòu)化設(shè)計等
實踐：TDD、OOP、結(jié)構(gòu)化編程、CI&CD&CD、結(jié)對編程
工件：UML圖、DFD圖、結(jié)構(gòu)圖、Petri網(wǎng)絡(luò)圖、狀態(tài)遷移圖表、流程圖、決策表

堅持學(xué)習(xí)
堅持練習(xí)（業(yè)精于勤）
合作
輔導(dǎo)（教學(xué)相長）
了解業(yè)務(wù)領(lǐng)域（熟悉行業(yè)背景，不能全按照規(guī)格說明去編碼，而是要能夠辨別、質(zhì)疑一些需求）
與雇主/客戶保持一致
謙遜（每個人都會犯錯，所以不要嘲笑別人，自己出錯了能坦然接收別人的嘲笑）

第二章 說“不”

能就是能，不能就是不能。不要說“試試看”。 - 尤達

這一章介紹了“專業(yè)程序員要竭盡所能地追求和捍衛(wèi)自身的目標(biāo)，從而會和管理者產(chǎn)生對抗”，“高風(fēng)險時刻更應(yīng)該說不”，“團隊精神是為整體目標(biāo)著想，而不是試試看”。而這些前提都是開發(fā)人員人員能夠做到較好的項目排期，并且有理有據(jù)地對管理者說“不”，同時也不能總說不，否則就是能力問題了。

第三章 說“是”

3.1 承諾用語

口頭上說、心理認(rèn)真、付諸行動。

“缺乏承諾的”的征兆：

1. 我們要。。。
2. 我需要。。。
3. 。。。應(yīng)當(dāng)。。。
4. 讓我們。。。
5. 希望。。。
6. 但愿。。。

真正的承諾：我將在（時間點）之前完成（某個任務(wù)）
言必行行必果，如果沒做到的話，要如何應(yīng)對呢？

1. 之所以沒成功，是因為我寄希望于某某去做這件事。
2. 之所以沒成功，是因為我不太確信是否真能完成得了
   即使目標(biāo)無法完成，也能全力前進，離目標(biāo)更近。
3. 之所以沒成功，是因為有些時候我真的無能為力。
   突發(fā)事件出現(xiàn)后，盡快去調(diào)整別人對你的預(yù)期（越快越好）。

總結(jié)：估算日期、確定最后期限、交流溝通等等，做出承諾會令人害怕，但是可以建立個人的信譽（reputation）。

3.2 學(xué)習(xí)如何說“是”

1. “試試”的另一面

   
   
   image.png
2. 堅守原則
   首先，測試、文檔、代碼整潔性這些是不能夠省略的，因為省略這些也不能保證更快完成。多年的經(jīng)驗是，打破這些紀(jì)律和原則，更會拖慢進度。
   然后，嘗試說服管理者確實無法做到，可以找
   最后，如果實在不行，必須要做到，也得給自己爭取利益，不管是加人也好、調(diào)休也好。

3.3 總結(jié)

專業(yè)人士不需要對所有請求都回答“是”。不過，應(yīng)該努力尋找創(chuàng)新的方法，盡可能做到有求必應(yīng)。當(dāng)專業(yè)人士給出肯定回答時，他們會使用承諾用語，以確保各方能夠明白無誤地理解承諾內(nèi)容。

第四章 編碼

4.1 做好準(zhǔn)備

編碼要求聚精會神，要避免：

1. 心煩意亂時寫代碼
2. 疲勞時寫代碼（比如加班，凌晨3點）
3. 焦慮時寫代碼

4.2 流態(tài)區(qū)

其實就是效率很高的狀態(tài)。
但是這種狀態(tài)其實是一種”淺層冥想”狀態(tài)，敲出的代碼會增多，但是理性思考就少了。
結(jié)對編程的好處在于任何一方都不會進入流態(tài)區(qū)。

4.3 阻塞

寫不出來的時候要學(xué)會調(diào)整狀態(tài)。做些事情，而不是死盯著屏幕。

4.4 調(diào)試

4.5 保持節(jié)奏

也就是調(diào)整狀態(tài)。

4.6 進度延遲

4.7 幫助他人

第五章 測試驅(qū)動開發(fā)

TDD不光是一種技巧，也是一種思維方式。
三大原則：

1. 編好失敗單元測試之前，不要編寫任何產(chǎn)品代碼。
2. 只要有一個單元測試失敗了，就不要再編寫代碼；無法通過編譯也是一種失敗情況。
3. 產(chǎn)品代碼恰好能夠讓當(dāng)前失敗的單元測試成功通過即可，不要多謝。

這樣測試代碼、產(chǎn)品代碼、測試代碼、產(chǎn)品代碼。。。同步增長，互為補充。

5.3 TDD的優(yōu)勢

1. 確定性
   單元測試通過了，對產(chǎn)品就有把握了。
2. 降低缺陷注入率
3. 勇氣
   有助于重構(gòu)、修改糟糕代碼
4. 文檔
   單元測試即文檔。
5. 設(shè)計
   測試代碼的一個問題是必須隔離出待測試的代碼，這樣有助于代碼的解耦，也就有助于開發(fā)出更好的設(shè)計。
   （先寫產(chǎn)品代碼，很容易寫出一大坨耦合的代碼，不利于測試；先寫測試代碼就可以避免）
6. 專業(yè)人士的選擇

5.4 TDD的局限

測試代碼也可能很糟糕。。。
還有一些其他場景，不適合TDD
等等

第六章 練習(xí)

為開源項目貢獻代碼。

第七章 驗收測試

7.1 需求的溝通

1. 避免過早精細(xì)化
   需求總會變化的，突發(fā)事件也總是會發(fā)生的，在這之前想要確定最終交付的一項項的功能，就有點浪費精力了。
2. 明確需求
   跟客戶直接隔著一層又一層，就會導(dǎo)致信息的丟失，也就會導(dǎo)致對需求理解的偏差。

7.2 驗收測試

1. 什么叫完成？
   QA + 需求方都確認(rèn)了，才叫完成。
2. 溝通
3. 自動化
4. 額外工作
   5.驗收測試什么時候?qū)懀烧l寫
   業(yè)務(wù)方+QA > 業(yè)務(wù)分析員+QA > QA > Dev
   避免同一個人既寫了代碼又寫了測試。
5. 測試的協(xié)商與被動推進
6. 驗收測試和單元測試
7. GUI及其他因素
8. CI

7.3 結(jié)論

編寫自動化的驗收測試可以避免交流中的誤解。

第八章 測試策略

8.1 QA應(yīng)該找不到錯誤

QA和Dev是一個團隊的，而不是對立的。

8.2 自動化測試金字塔

從下往上，覆蓋率由高到低：
單元測試，組件測試，集成測試，系統(tǒng)測試，Web自動化測試，人工探索式測試。

第九章 時間管理

9.1 會議

1. 拒絕一些會議
2. 提前離席
3. 確定議程與目標(biāo)
4. 站會（盡可能快）
5. 迭代計劃會議
6. Retro
7. 爭論/反對（爭論之所以花費很多時間，是因為各方都拿不出有力的證據(jù)）

9.2 注意力（精力）

1. 睡眠
2. 咖啡因
3. 恢復(fù)
4. 肌肉注意力
5. 輸入與輸出

9.3 時間拆分和番茄工作法

劃分時間段，比如25分鐘一個時間段，這段時間內(nèi)只做一件事，25分鐘結(jié)束后再處理這段時間內(nèi)發(fā)生的事情。
25分鐘專注+5分鐘休息，4輪過后休息30分鐘。

9.4 排好優(yōu)先級

9.5 避免死胡同里浪費時間

9.6 避免陷入泥潭

9.7 結(jié)論

專業(yè)開發(fā)人員要注意管理自己的時間和精力，排好優(yōu)先級，認(rèn)清當(dāng)前的狀況，并避免走入死胡同和陷入泥潭。

第十章 預(yù)估

第二章 說“不” 里已經(jīng)提到了預(yù)估的重要性。

10.1 區(qū)分預(yù)估和承諾

10.3 預(yù)估任務(wù)

按照斐波那契數(shù)列預(yù)估（1，2，3，5，8）

10.4 大數(shù)定律

大任務(wù)分割為小任務(wù)，預(yù)估，加和，這樣預(yù)估準(zhǔn)確率高一些

10.5 結(jié)論

專業(yè)開發(fā)人員一旦做了承諾，就會提供確定的數(shù)字，按時兌現(xiàn)。
但是大多數(shù)情況下，他們不會做這種承諾，而是提供概率預(yù)估，來描述期望的完成時間和可能的變數(shù)。

第十一章 壓力

11.1 避免壓力

1. 承諾
2. 保持整潔
3. 危機中的紀(jì)律

11.2 應(yīng)對壓力

1. 不要慌張
2. 溝通
3. 依靠紀(jì)律原則
4. 尋求幫助

11.3 結(jié)論

能回避壓力的時候盡可能回避，無法回避時則勇敢直面壓力。
可以通過慎重承諾、遵循自己的紀(jì)律原則、保持整潔來回避壓力。
直面壓力時，保持冷靜，多與人溝通，堅持原則，尋求他人幫助。

第十二章 協(xié)作

12.1 程序員與人

1. 與雇主
   多了解業(yè)務(wù)
2. 與程序員
   互相學(xué)習(xí)、互相幫助

12.3 結(jié)論

編程就意味著與人協(xié)作，與人交流。

第十三章 團隊與項目

13.1 只是簡單的混合嗎

1. 有凝聚力的團隊
2. 如何管理有凝聚力的團隊
3. 項目承包人的困境

13.2 結(jié)論

團隊比項目更難構(gòu)建。因此，組件穩(wěn)健的團隊，接手一個又一個的項目，整體移動，形成凝聚力，不斷磨合，一直共同工作，成為不斷交付項目的強大引擎。

第十四章 輔導(dǎo)、學(xué)徒期與技藝

14.1 失敗的學(xué)位教育

14.2 輔導(dǎo)

14.3 學(xué)徒期

14.4 技藝

14.5 結(jié)論

學(xué)校傳授的是計算機編程的理論，還缺少原則、實踐、技能。需要軟件行業(yè)中的每一代人去引導(dǎo)下一代人。

讀后感

這本書的內(nèi)容本身就很務(wù)虛，作者通過大量的、大段的舉例說明，來描述他想要表達的思想。
而這些思想又不是各自獨立的，分為十四個章節(jié)，相互交織在一起，導(dǎo)致一些重復(fù)（比如多次提到需要溝通，還有關(guān)于測試，團隊協(xié)作，團隊精神等等），所以顯得有些混亂。
同時這十四個章節(jié)涵蓋的面又有些廣，從個人技能到與人協(xié)作，再到輔導(dǎo)、學(xué)徒，稍顯零散。

不過可以看出，這些思想是作者經(jīng)年累月的寶貴的人生經(jīng)驗，還是可以讓讀者在多個方面產(chǎn)生共鳴的。
記住這些經(jīng)驗，在工作中時刻提醒自己，一定可以有所收獲的。

簡單地總結(jié)一下：

1. 提高預(yù)估、排期的能力，從而可以從容地說“不”，說“是”，提高個人的聲譽，減小壓力；
2. 溝通交流，不僅要與業(yè)務(wù)方交流業(yè)務(wù)，還要與管理者交流進度，還要與其他程序員交流技術(shù)，互相幫助；
3. 管理好時間，不光是工作上，減少無意義的會議、管理精力、排好優(yōu)先級、避免死胡同和泥潭，還要給自己保留提升個人技藝的時間，勤加練習(xí)；
4. 建立個人的原則，例如不輕易承諾、保持整潔、不能為了工期而削減測試代碼等等，這些紀(jì)律也可以幫助你說“不”，說“是”，以及應(yīng)對壓力；
5. 團隊凝聚力是完成項目的前提；
6. 怎么才算完成？開發(fā)人員要做到自己測試沒問題，然后再交給QA，等QA和業(yè)務(wù)方都確認(rèn)后才算完成。
   不是說代碼寫完了就完了的。

做到了上面的這些，才能算作專業(yè)人士，才能算是具有程序員的職業(yè)素養(yǎng)！

P.S. 雖然本身很務(wù)虛，但也通過大量的舉例，提出了一些務(wù)實的建議和方法，比如：

1. 多了解技能領(lǐng)域：設(shè)計模式、設(shè)計原則、方法、實踐、工件等
2. 編碼是一項腦力+體力勞動，所以需要身體做好準(zhǔn)備，要避免疲勞、焦慮時編碼
3. 時間管理里，減少會議時間、減少無意義的爭論（讓數(shù)據(jù)說話）
4. 預(yù)估任務(wù)時，（1，2，3，5，8），拆分任務(wù)再預(yù)估
5. 項目交付快要失敗前，及時溝通，降低別人的期望，保護你自己的聲譽，也減小你的壓力