敏捷開發
軟體設計關乎抽象化，而抽象化需要訓練與練習。
缺乏抽象能力，無法靠 SCRUM 或 AGILE 流程來彌補。
最糟的情況，就是先拉在褲子裡，然後下個 Sprint 再洗褲子。
需求／系統分析
描述人類必須如何做事，而不是電腦將如何做事。
IT 專業
有責任感的程式設計師會學習程式語言、框架與工具背後的哲學。
你不必在一天內知道所有事情，
你該做的是每天多學一點。
不負責任的程式設計師會自行發明錯誤處理方式、容易出錯的設計等等。
簡單
- 不要發明必須由他人記住的事物。
- 若某件事不經思考就會被觸發，最壞的結果應該是無害的。
- 如果某件事必須被記住，最好它已經寫在官方文件中。
- 對於瑣碎的事，自動化測試可確保無誤的環境。
寫程式
「感覺」不能作為好風格的理由。
單元測試讓你能檢視自己的設計。
複雜的單元測試意味著複雜的設計，
這代表設計不佳，
也指出了容易出錯的程式碼片段。
單元測試
- 你不知道未來會需要測試程式碼多少次。
- 每測試一次程式碼，你就必須付出 $1。
- 撰寫單元測試只要付出 $5，未來便能免費執行測試。
沒有他媽的藉口。
學習
- 閱讀經得起時間考驗的書籍時，要謙虛且保持求知若渴。
- 小心程式碼片段。
撰寫文件
用撰寫文件來釐清思緒。
如果你能有效地寫作，你就能有效地寫程式。
把自己當成你的讀者；他無法與你面對面交流。
不稱職的程式設計師同樣會寫出難以閱讀的文件。
工作哲學
在發明任何事物之前，先試著閱讀框架、語言與工具文件的目錄。
不稱職程式設計師的遞迴過程：
- 「我沒有時間學習 X，所以只好花大量的 X^2 時間來修正它。」
全貌
- 如果日常工作只需要用到 Git 的少數功能，
代表你一定做對了某些事。
- 如果我們持續討論工單系統的規則，
代表我們必須管理大量缺陷。
無知
- 「修補緊急問題所花的時間，比撰寫單元測試更短。」
- 「我的程式碼是自我文件化的。」
- 我希望作業系統／編譯器／框架／函式庫／資料庫的開發者，也能對他們的使用者說同樣的話。
- 「CI/CD 可以解決一切，即使同一個功能在一小時內連續緊急修補 5 次。」
- 「為了日後可能替換的情況，我不得不抽象化
StringUtils.trim()（Apache Common Lang）。」