第一章 專業主義

1.1 清楚你要什麼

專業主義的精髓在於將公司利益視同個人利益。所以犯錯不是“在所難免的”，而是應當極力避免，並勇於承擔後果。

1.2 擔當責任

1.3 不行損害之事

1. 不破壞軟體功能
   讓QA找不出問題，而不是讓QA幫忙檢查
2. 確信程式碼能正常執行
   要考慮單元測試，測試覆蓋率，測試驅動開發（TDD）
3. 自動化QA
4. 不破壞結構
   所有軟體專案的根本指導原則是：軟體要易於修改。
   不破壞結構並不表示儘量少修改程式碼，相反，如果期望自己的軟體靈活可變，就應該時常修改它。
   事實是，大多數開發人員不敢不斷修改程式碼，因為害怕改壞了。這裡就又回到上面的“自動化測試”，如果有自動化測試，並且測試覆蓋率也很高，那麼就不會害怕改壞了。

1.4 職業道德

職業發展是個人的事情，僱主沒有義務考慮這些，也沒有義務給你培訓，送你參加會議等等。

職業道德是：
1. 你自己要計劃每週工作的時間，比如60小時，其中40小時是給僱主的，剩下的20小時是給自己做提升使用。
2. 瞭解你的領域
工作中涉及到的東西都要去了解，否則只能寫寫 if-else, while 之類的程式碼了。

以下是每個專業軟體開發人員必須精通的事項：
設計模式：GoF 書中（設計模式）的23種模式
設計原則：必須瞭解SOLID原則，而且要深刻理解元件設計原則
方法：XP、Scrum、精益、看板、瀑布、結構化分析、結構化設計等
實踐：TDD、OOP、結構化程式設計、CI&CD&CD、結對程式設計
工件：UML圖、DFD圖、結構圖、Petri網路圖、狀態遷移圖表、流程圖、決策表

堅持學習
堅持練習（業精於勤）
合作
輔導（教學相長）
瞭解業務領域（熟悉行業背景，不能全按照規格說明去編碼，而是要能夠辨別、質疑一些需求）
與僱主/客戶保持一致
謙遜（每個人都會犯錯，所以不要嘲笑別人，自己出錯了能坦然接收別人的嘲笑）

第二章 說“不”

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

這一章介紹了“專業程式設計師要竭盡所能地追求和捍衛自身的目標，從而會和管理者產生對抗”，“高風險時刻更應該說不”，“團隊精神是為整體目標著想，而不是試試看”。而這些前提都是開發人員人員能夠做到較好的專案排期，並且有理有據地對管理者說“不”，同時也不能總說不，否則就是能力問題了。

第三章 說“是”

3.1 承諾用語

口頭上說、心理認真、付諸行動。

“缺乏承諾的”的徵兆：
1. 我們要。。。
2. 我需要。。。
3. 。。。應當。。。
4. 讓我們。。。
5. 希望。。。
6. 但願。。。

真正的承諾：我將在（時間點）之前完成（某個任務）
言必行行必果，如果沒做到的話，要如何應對呢？
1. 之所以沒成功，是因為我寄希望於某某去做這件事。
2. 之所以沒成功，是因為我不太確信是否真能完成得了
即使目標無法完成，也能全力前進，離目標更近。
3. 之所以沒成功，是因為有些時候我真的無能為力。
突發事件出現後，儘快去調整別人對你的預期（越快越好）。

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

3.2 學習如何說“是”

1. “試試”的另一面
   
2. 堅守原則
   首先，測試、文件、程式碼整潔性這些是不能夠省略的，因為省略這些也不能保證更快完成。多年的經驗是，打破這些紀律和原則，更會拖慢進度。
   然後，嘗試說服管理者確實無法做到，可以找
   最後，如果實在不行，必須要做到，也得給自己爭取利益，不管是加人也好、調休也好。

3.3 總結

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

第四章 編碼

4.1 做好準備

編碼要求聚精會神，要避免：
1. 心煩意亂時寫程式碼
2. 疲勞時寫程式碼（比如加班，凌晨3點）
3. 焦慮時寫程式碼

4.2 流態區

其實就是效率很高的狀態。
但是這種狀態其實是一種”淺層冥想”狀態，敲出的程式碼會增多，但是理性思考就少了。
結對程式設計的好處在於任何一方都不會進入流態區。

4.3 阻塞

寫不出來的時候要學會調整狀態。做些事情，而不是死盯著螢幕。

4.4 除錯

4.5 保持節奏

也就是調整狀態。

4.6 進度延遲

4.7 幫助他人

第五章 測試驅動開發

TDD不光是一種技巧，也是一種思維方式。
三大原則：
1. 編好失敗單元測試之前，不要編寫任何產品程式碼。
2. 只要有一個單元測試失敗了，就不要再編寫程式碼；無法通過編譯也是一種失敗情況。
3. 產品程式碼恰好能夠讓當前失敗的單元測試成功通過即可，不要多謝。

這樣測試程式碼、產品程式碼、測試程式碼、產品程式碼。。。同步增長，互為補充。

5.3 TDD的優勢

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

5.4 TDD的侷限

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

第六章 練習

為開源專案貢獻程式碼。

第七章 驗收測試

7.1 需求的溝通

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

7.2 驗收測試

1. 什麼叫完成？
   QA + 需求方都確認了，才叫完成。
2. 溝通
3. 自動化
4. 額外工作
   5.驗收測試什麼時候寫，由誰寫
   業務方+QA > 業務分析員+QA > QA > Dev
   避免同一個人既寫了程式碼又寫了測試。
5. 測試的協商與被動推進
6. 驗收測試和單元測試
7. GUI及其他因素
8. CI

7.3 結論

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

第八章 測試策略

8.1 QA應該找不到錯誤

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

8.2 自動化測試金字塔

從下往上，覆蓋率由高到低：
單元測試，元件測試，整合測試，系統測試，Web自動化測試，人工探索式測試。

第九章 時間管理

9.1 會議

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

9.2 注意力（精力）

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

9.3 時間拆分和番茄工作法

劃分時間段，比如25分鐘一個時間段，這段時間內只做一件事，25分鐘結束後再處理這段時間內發生的事情。
25分鐘專注+5分鐘休息，4輪過後休息30分鐘。

9.4 排好優先順序

9.5 避免死衚衕裡浪費時間

9.6 避免陷入泥潭

9.7 結論

專業開發人員要注意管理自己的時間和精力，排好優先順序，認清當前的狀況，並避免走入死衚衕和陷入泥潭。

第十章 預估

第二章 說“不” 裡已經提到了預估的重要性。

10.1 區分預估和承諾

10.3 預估任務

按照斐波那契數列預估（1，2，3，5，8）

10.4 大數定律

大任務分割為小任務，預估，加和，這樣預估準確率高一些

10.5 結論

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

第十一章 壓力

11.1 避免壓力

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

11.2 應對壓力

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

11.3 結論

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

第十二章 協作

12.1 程式設計師與人

1. 與僱主
   多瞭解業務
2. 與程式設計師
   互相學習、互相幫助

12.3 結論

程式設計就意味著與人協作，與人交流。

第十三章 團隊與專案

13.1 只是簡單的混合嗎

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

13.2 結論

團隊比專案更難構建。因此，元件穩健的團隊，接手一個又一個的專案，整體移動，形成凝聚力，不斷磨合，一直共同工作，成為不斷交付專案的強大引擎。

第十四章 輔導、學徒期與技藝

14.1 失敗的學位教育

14.2 輔導

14.3 學徒期

14.4 技藝

14.5 結論

學校傳授的是計算機程式設計的理論，還缺少原則、實踐、技能。需要軟體行業中的每一代人去引導下一代人。

讀後感

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

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

簡單地總結一下：
1. 提高預估、排期的能力，從而可以從容地說“不”，說“是”，提高個人的聲譽，減小壓力；
2. 溝通交流，不僅要與業務方交流業務，還要與管理者交流進度，還要與其他程式設計師交流技術，互相幫助；
3. 管理好時間，不光是工作上，減少無意義的會議、管理精力、排好優先順序、避免死衚衕和泥潭，還要給自己保留提升個人技藝的時間，勤加練習；
4. 建立個人的原則，例如不輕易承諾、保持整潔、不能為了工期而削減測試程式碼等等，這些紀律也可以幫助你說“不”，說“是”，以及應對壓力；
5. 團隊凝聚力是完成專案的前提；
6. 怎麼才算完成？開發人員要做到自己測試沒問題，然後再交給QA，等QA和業務方都確認後才算完成。
不是說程式碼寫完了就完了的。

做到了上面的這些，才能算作專業人士，才能算是具有程式設計師的職業素養！

P.S. 雖然本身很務虛，但也通過大量的舉例，提出了一些務實的建議和方法，比如：
1. 多瞭解技能領域：設計模式、設計原則、方法、實踐、工件等
2. 編碼是一項腦力+體力勞動，所以需要身體做好準備，要避免疲勞、焦慮時編碼
3. 時間管理裡，減少會議時間、減少無意義的爭論（讓資料說話）
4. 預估任務時，（1，2，3，5，8），拆分任務再預估
5. 專案交付快要失敗前，及時溝通，降低別人的期望，保護你自己的聲譽，也減小你的壓力