●序XVII
新版前言XXI
第一版前言XV
提示1：關注你的技藝XVII
如果你不關心怎麼做好，為什麼還要花時間去開發軟件呢？
提示2：思考！思考你的工作XVII
關掉輔助駕駛，由自己掌控，持續不斷地評估所做的工作。
第1章務實的哲學1
1人生是你的2
提示3：你有權選擇3
人生是自己的。把握住人生，讓它如你所願。
2我的源碼被貓喫了3
提示4：提供選擇，別找借口5
提供選擇而不是去找理由。不要隻說做不到；解釋一下都能做些什麼。
3軟件的熵6
提示5：不要放任破窗7
隻要看到不好的設計、錯誤的決策、糟糕的代碼，就趕緊去糾正。
4石頭做的湯和煮熟的青蛙9
提示6：做推動變革的催化劑10
你無法強迫人們去改變，但可以展示美好未來，並幫助他們參與創造。
提示7：牢記全景10
不要過度沉浸於細枝末節，以免察覺不到周圍正在發生的事情。
5夠好即可的軟件11
提示8：將質量要求視為需求問題12
讓用戶參與對項目真實質量需求的確定。
6知識組合14
提示9：對知識組合做定期投資16
養成學習的習慣。
提示10：批判性地分析你讀到和聽到的東西18
不要受供應商、媒體炒作或教條的影響，根據自身和項目的實際情況來分析信息。
7交流！20
提示11：英語就是另一門編程語言20
將英語視作一門編程語言。寫文檔和編程一樣要遵循DRY原則、ETC、自動化等。
提示12：說什麼和怎麼說同樣重要23
如果無法有效交流，任何偉大的想法都是沒有意義的。
提示13：把文檔嵌進去，而不要栓在表面24
與代碼隔離的文檔，很難保持正確並及時更新。
第2章務實的方法27
8優秀設計的精髓28
提示14：優秀的設計比糟糕的設計更容易變更28
適合使用者的事物，都已經過良好設計。對代碼來說，這意味著必須適應變化。
9DRY——邪惡的重復30
提示15：DRY——不要重復自己31
繫統中的每一條知識，都必須有單一且無歧義的權威陳述。
提示16：讓復用變得更容易39
隻要復用方便，人們就會去做。創建一個支持復用的環境。
10正交性40
提示17：消除不相關事物之間的影響41
設計的組件，需要自成一體、獨立自主，有單一的清晰定義的意圖。
11可逆性48
提示18：不設最終決定50
不要把決定刻在石頭上，而要將其視為寫在沙灘上的東西，時刻準備應變。
提示19：放棄追逐時尚50
尼爾?福特說過：“昨日之很好實踐，即明日之反模式。”要基於基本原則去選擇架構，而不應盲從於流行。
12曳光彈51
提示20：使用曳光彈找到目標53
通過不斷嘗試並看清著彈點，曳光彈可確保你最終擊中目標。
13原型與便簽57
提示21：用原型學習58
制作原型旨在學習經驗，其價值不在於過程中產生的代碼，而在於得到的教訓。
14領域語言60
提示22：靠近問題域編程61
用問題領域的語言來做設計和編程。
15估算67
提示23：通過估算來避免意外67
開始之前做估算，能提前發現潛在問題。
提示24：根據代碼不斷迭代進度表72
利用實施過程中獲得的經驗來精細化項目的時間尺度。
第3章基礎工具74
16純文本的威力75
提示25：將知識用純文本保存76
純文本不會過時。它能夠讓你的工作事半功倍，並能簡化調試和測試工作。
17Shell遊戲79
提示26：發揮Shell命令的威力80
當圖形化界面無法勝任時，使用Shell。
18加強編輯能力82
提示27：遊刃有餘地使用編輯器82
既然編輯器是至關重要的工具，不妨了解一下如何用它更快更準確地實現需求。
19版本控制85
提示28：永遠使用版本控制87
版本控制為你的工作創造了一個時間機器，可以用它重返過去。
20調試90
提示29：去解決問題，而不是責備91
Bug到底來自你的失誤還是別人的失誤真的不重要——它終究是你的問題，需要你來修復。
提示30：不要恐慌91
不管是對銀河繫搭車客，還是對開發者來說，都應這樣。
提示31：修代碼前先讓代碼在測試中失敗93
在你修Bug前，先創建一個聚焦於該Bug的測試。
提示32：讀一下那些該死的出錯信息93
大多數異常都能告訴失敗之物與失敗之處。如果足夠幸運，你甚至能得到具體的參數值。
提示33：“select”沒出問題97
在操作繫統或編譯器中發現Bug非常罕見，甚至在第三方產品或庫中也是如此。Bug大多出現在應用程序中。
提示34：不要假設，要證明97
在真實環境中證實你的假設——要依賴真實的數據及邊界條件。
21文本處理99
提示35：學習一門文本處理語言99
既然每天都要花大量的時間與文本打交道，何不讓計算機幫你分擔一二？
22工程日記101
第4章務實的偏執103
提示36：你無法寫出完美的軟件103
軟件不可能是完美的。對於在所難免的錯誤，要保護代碼和用戶免受其影響。
23契約式設計104
提示37：通過契約進行設計107
代碼是否不多不少剛好完成它宣稱要做的事情，可以使用契約加以校驗和文檔化。
24死掉的程序不會說謊113
提示38：盡早崩潰114
死掉的程序通常比有缺陷的程序造成的損害要小。
25斷言式編程115
提示39：使用斷言去預防不可能的事情115
如果一件事情不可能發生，那麼就用斷言來確保其的確不會發生。斷言在校驗你的假設，要使用斷言在不確定的世界中將你的代碼保護起來。
26如何保持資源的平衡119
提示40：有始有終119
隻要有可能，對資源進行分配的函數或對像就有責任去釋放該資源。
提示41：在局部行動122
將易變的變量維持在一個範圍內，打開資源的過程要短暫且明顯可見。
27不要衝出前燈範圍127
提示42：小步前進——由始至終127
永遠小步前進，不斷檢查反饋，並且在推進前先做調整。
提示43：避免129
隻在你能看到的範圍內做計劃。
第5章寧彎不折130
28解耦131
提示44：解耦代碼讓改變更容易132
耦合使事物緊緊綁定在一起，以至於很難隻改變其中之一。
提示45：隻管命令不要詢問133
不要從對像中取出值，在加以變換後再塞回去，讓對像自己來完成這些工作。
提示46：不要鏈式調用方法135
當訪問某事物時，使用的點號不要超過一個。
提示47：避免全局數據137
優選給每個方法增加一個額外的參數。
提示48：如果全局專享非常重要，那麼將它包裝到API中137
……但是，僅限於你真的非常希望它是全局的。
29在現實世界中拋球雜耍139
30變換式編程149
提示49：編程講的是代碼，而程序談的是數據151
所有的程序都在變換數據——將輸入轉換為輸出。開始用變換式方法來設計吧！
提示50：不要囤積狀態，傳遞下去156
不要把數據保持在函數或模塊的內部，拿出來傳遞下去。
31繼承稅162
提示51：不要付繼承稅165
考慮一下能更好滿足需求的替代方案，比如接口、委托或mixin。
提示52：盡量用接口來表達多態167
無需繼承引入的耦合，接口就能明確描述多態性。
提示53：用委托提供服務：“有一個”勝過“是一個”167
不要從服務中繼承，應該包含服務。
提示54：利用mixin共享功能169
mixin不必承擔繼承稅就可以給類添加功能，而與接口結合可以讓多態不再令人痛苦。
32配置170
提示55：使用外部配置參數化應用程序170
如果代碼對一些在應用程序發布後還有可能改變的值有所依賴，那麼就在應用外部維護這些值。
第6章並發174
33打破時域耦合175
提示56：通過分析工作流來提高並發性176
利用用戶工作流中的並發性。
34共享狀態是不正確的狀態179
提示57：共享狀態是不正確的狀態180
共享狀態會帶來無窮的麻煩，而且往往隻有重啟纔能解決。
提示58：隨機故障通常是並發問題186
或許時間和上下文的變化能暴露並發Bug，但並發Bug無法始終保持一致，也很難重現。
35角色與進程187
提示59：用角色實現並發性時不必共享狀態188
使用角色來管理並發狀態，可以避免顯式的同步。
36黑板193
提示60：使用黑板來協調工作流195
使用黑板來協調不相關的事實和代理人，能同時保持參與者之間的獨立性和孤立性。
第7章當你編碼時198
37聽從蜥蜴腦199
提示61：傾聽你內心的蜥蜴201
當編程舉步維艱時，其實是潛意識在告訴你有什麼地方不對勁。
38巧合式編程204
提示62：不要依賴巧合編程207
隻能依賴可靠的事物。注意偶然事件的復雜性，不要混淆快樂的巧合與有目的的計劃。
39算法速度210
提示63：評估算法的級別214
在開始編程前，對這件事情大概會花多長時間要有概念。
提示64：對估算做測試214
針對算法的數學分析無法說明所有問題，嘗試在目標環境中測試一下執行代碼的耗時。
40重構216
提示65：盡早重構，經常重構219
像除草和翻整花園那樣，隻要有需要就對代碼進行重新編寫、修訂和架構，以便找到問題的根源並加以修復。
41為編碼測試220
提示66：測試與找Bug無關221
測試是觀察代碼的一個視角，可以從中得到針對設計、接口和耦合度的反饋。
提示67：測試是代碼的第一個用戶222
用測試的反饋來引導工作。
提示68：既非自上而下，也不自下而上，基於端對端構建225
創建一小塊端到端的功能，從中獲悉問題之所在。
提示69：為測試做設計228
寫下代碼之前先從測試角度思考。
提示70：要對軟件做測試，否則隻能留給用戶去做230
無情地測試，不要等用戶來幫你找Bug。
42基於特性測試231
提示71：使用基於特性的測試來校驗假設231
基於特性的測試將會進行你從未想過的嘗試，並會以你不曾打算采用的方式操練你的代碼。
43出門在外注意安全238
提示72：保持代碼簡潔，讓攻擊面最小241
復雜的代碼給Bug以滋生之沃土，給攻擊者以可趁之機。
提示73：盡早打上安全補丁243
攻擊者會盡可能快地部署攻擊，你必須快上加快。
44事物命名245
提示74：好好取名；需要時更名249
用名字向讀者表達你的意圖，並且在意圖改變時及時更名。
第8章項目啟動之前251
45需求之坑252
提示75：無人確切知道自己想要什麼252
他們或許知道大概的方向，但不會了解過程的曲折。
提示76：程序員幫助人們理解他們想要什麼253
軟件開發更像是一種由用戶和程序員協同創造的行為。
提示77：需求是從反饋循環中學到的254
理解需求需要探索和反饋，因此決策的結果可以用來完善最初的想法。
提示78：和用戶一起工作以便從用戶角度思考255
這是看透繫統將如何被真正使用的很好方法。
提示79：數據256
不要將策略硬編碼進繫統，而應該將其表達為繫統數據。
提示80：使用項目術語表259
為項目的所有特定詞彙創建一張術語表，並且在單一源頭維護。
46處理無法解決的難題260
提示81：不要跳出框框思考——找到框框261
在面對無法解決的難題時，識別出真正的約束。可以問自己：“必須這樣做纔能搞定嗎？必須搞定它嗎？”
47攜手共建264
提示82：不要一個人埋頭鑽進代碼中267
編程往往困難又費力，找個朋友和你一起干。
提示83：敏捷不是一個名詞；敏捷有關你如何做事267
敏捷是一個形容詞，有關如何做事情。
48敏捷的本質267
第9章務實的項目271
49務實的團隊272
提示84：維持小而穩定的團隊272
團隊應保持穩定、小巧，團隊中的每個人都應相互信任、互相依賴。
提示85：排上日程以待其成274
如果你不把事情納入日程表，它們就不會發生。反思、實驗、學習、提高技能，這些事都應放入日程表。
提示86：組織全功能的團隊276
圍繞功能而不是工作職能組織團隊。不要將UI/UX設計者從程序員中分離出去，也不要分開前端和後端；不要區分數據建模者和測試人員，以及開發和設計。構建一個團隊，這樣你就可以漸進地不斷迭代端到端的代碼。
50椰子派不上用場277
提示87：做能起作用的事，別趕時髦279
不要僅僅因為別的公司正在那麼干就采納一項技術或采用一個開發方法，而是要采用自己所處環境中對團隊有效的東西。
提示88：在用戶需要時交付281
不要卡著流程要求，刻意等到幾周甚至幾個月後纔交付。
51務實的入門套件281
提示89：使用版本控制來驅動構建、測試和發布282
利用提交或推送來觸發構建、測試、發布，利用版本控制的標簽來進行生產部署。
提示90：盡早測試，經常測試，自動測試283
每次構建都跑一下的測試，要比束之高閣的測試計劃有效得多。
提示91：直到所有的測試都已運行，編碼纔算完成283
無須多言。
提示92：使用破壞者檢測你的測試285
在一個單獨的源碼副本中特意引入Bug，驗證測試能否將其捕獲。
提示93：測試狀態覆蓋率，而非代碼覆蓋率286
要識別並測試重要的程序狀態，隻測試一行行的代碼是不夠的。
提示94：每個Bug隻找一次286
隻要人類測試者找到一個Bug，就應該是該Bug最後一次被人類發現。從此之後，自動化測試接近可以發現它。
提示95：不要使用手動程序287
計算機能一次又一次，按照同樣的次序，執行相同的指令。
52取悅用戶288
提示96：取悅用戶，而不要隻是交付代碼289
為用戶開發能夠帶來商業價值的解決方案，並讓他們每天都感到愉快。
提示97：在作品上簽名290
過去的工匠在為他們的作品簽名時非常自豪，你也應該這樣。
53傲慢與偏見290
跋292
提示98：先勿傷害293
犯錯在所難免，確保犯錯後沒人會因此受難。
提示99：不要助紂為虐294
因為這樣做你也有變成紂王的風險。
參考文獻295
練習的參考答案297
譯者跋312

《程序員修煉之道》之所以在全球範圍內廣泛傳播，被一代代開發者奉為圭臬，蓋因它可以創造出真正的價值：或編寫出更好的軟件，或探究出編程的本質，而所有收獲均不依賴於特定語言、框架和方法。時隔20年的新版，經過全面的重新選材、組織和編寫，覆蓋哲學、方法、工具、設計、解耦、並發、重構、需求、團隊等務實話題的很好實踐及重大陷阱，以及易於改造、復用的架構技術。本書極具洞察力與趣味性，適合從初學者到架構師的各階層讀者潛心研讀或增廣見聞。