程序員修煉之道：通向務實的最高境界（第2版）(博文視點出品)

[美] David，Thomas（大衛(wèi)托馬斯），Andrew，Hunt（安德魯亨特） 著，云風 譯

• 出版社： 電子工業(yè)出版社
• ISBN：9787121384356
• 版次：2
• 商品編碼：12828404
• 品牌：博文視點
• 包裝：平裝
• 開本：16開
• 出版時間：2020-04-01
• 用紙：膠版紙
• 頁數(shù)：344
• 字數(shù)：505000

點此購買

編輯推薦

適讀人群 ：無論你是一個新的程序員，一個有經(jīng)驗的程序員，還是一個負責軟件項目的經(jīng)理，都會通過本書獲得個人生產力、準確性和工作滿意度的提高，從中習得的學習技能、習慣和態(tài)度，都將是你在職業(yè)生涯中獲得長期成功的基礎。

√ 屹立 20 年影響力大作，成功案例數(shù)以千萬計，凌駕于任何語言|框架|方法之上。

√ 面向未來重寫全部內容，從程序員責任與職業(yè)發(fā)展，到靈活|易適配|可重用架構。

√ 53個核心話題|99個高能提示，闡明軟件開發(fā)走向卓越之路及途中各種典型陷阱。

√ 編程界傳奇人物云風操刀翻譯，至理|奧義|案例|技巧之原著精微，無不掘至毫巔。

◎與“軟件腐爛”做斗爭

◎持續(xù)學習

◎避免知識重復的陷阱

◎寫出有彈性、動態(tài)、適配性強的代碼

◎駕馭基本工具的力量

◎避免依賴巧合編程

◎學習真正的需求

◎解決并發(fā)代碼的底層問題

◎防范安全漏洞

◎建立務實程序員構成的團隊

◎對你的工作和事業(yè)負責

◎無情而有效地做測試，包括基于特性的測試

◎組建務實的入門套件

◎取悅你的用戶

內容簡介

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

作者簡介

譯者云風（真名吳云洋），曾任網(wǎng)易杭州研究中心總監(jiān)，是網(wǎng)易《大話西游》《夢幻西游》等知名游戲的主要開發(fā)者；2011 年與前網(wǎng)易 COO 詹鐘暉聯(lián)合創(chuàng)辦簡悅（EJOY）游戲公司，兼任 CTO，現(xiàn)該公司已被阿里收購；在互聯(lián)網(wǎng)、游戲界擁有較高技術影響力，常年發(fā)表博客文章，并著有《游戲之旅》及《Effective C++（評注版）》。

精彩書評

這樣的贊美一直不絕于耳：通過撰寫一本書來推動整個行業(yè)，是 Andy 和 Dave 用《程序員修煉之道：從小工到專家》完成的一大壯舉，無人可以超過。然而，有時兩次閃電的確會擊中同一個地方，這部名著的再版即為明證。其令人震撼的內容更新，足以確保自身在未來二十年里繼續(xù)雄踞“精選軟件開發(fā)圖書”榜單之首，此可謂實至名歸。

—— VM (Vicky) Brasseur

瞻博網(wǎng)絡開源戰(zhàn)略總監(jiān)

如果想讓自己的軟件既領先于時代又易于維護，就在手邊擺放一本《程序員修煉之道：通向務實的最高境界（第2版）》。本書充滿實用建議，有技術方面的，也有專業(yè)方面的，無不能讓你和你的項目受益多年。

—— Andrea Goulet

Corgibytes 公司 CEO

LegacyCode.Rocks 創(chuàng)始人

可以說，《程序員修煉之道》完全改變了我的職業(yè)軌跡，為我指明了軟件領域的成功方向。正是這本書，開闊了我的視野，讓我意識到自己不僅僅是龐大機器上的一枚齒輪，有朝一日也能藉由修煉成為匠師。它是我生命中重要的一本書。

—— Obie Fernandez

《Rails 之道》作者

初讀此書的讀者，在見識到那個軟件開發(fā)實踐的新世界時，立刻充滿期待。而第一版圖書，對塑造這樣一個迷人的現(xiàn)代世界，的確厥功至偉?，F(xiàn)在，第一版的讀者將有機會在新版中重溫舊夢，再次接受洞察力和實踐智慧的洗禮，而《程序員修煉之道》當初正因此被奉為圭臬。更重要的是，經(jīng)由兩位專家親手組織與更新的再版圖書，業(yè)已因富含新知而重煥青春。

—— David A. Black

《Ruby程序員修煉之道》作者

舊版的《程序員修煉之道》一直駐留在我的書架上。從很久以前它改變我作為一個程序員的工作方式那一刻起，我讀了又讀。在這個全新的版本中，一切似乎都已改變，而一切又仿佛還在那里。雖然我們現(xiàn)在換用 iPad 閱讀新版，其代碼示例也改由現(xiàn)代編程語言實現(xiàn)——但是蘊藏其中的概念、思想和態(tài)度，亙古不變且通行宇宙。二十年過去，這本書的價值從未折損。現(xiàn)在乃至將來的開發(fā)人員，都有機會從 Andy 和 Dave 的深刻洞見中獲益，正如當年的我一樣，這讓人備感欣慰。

—— Sandy Mamoli

敏捷教練

How Self-Selection Lets People Excel 作者

二十年前，《程序員修煉之道》的第一版徹底顛覆了我的技術生涯。這次的新版，也將對你有此影響。

—— Mike Cohn

《Scrum敏捷軟件開發(fā)》

《敏捷估計與規(guī)劃》

《用戶故事與敏捷方法》作者

目錄

序 XVII

新版前言 XXI

第一版前言 XV

提示1：關注你的技藝 XVII

如果你不關心怎么做好，為什么還要花時間去開發(fā)軟件呢？

提示2：思考！思考你的工作 XVII

關掉輔助駕駛，由自己掌控，持續(xù)不斷地評估所做的工作。

第1章 務實的哲學 1

1 人生是你的 2

提示3：你有權選擇 3

人生是自己的。把握住人生，讓它如你所愿。

2 我的源碼被貓吃了 3

提示4：提供選擇，別找借口 5

提供選擇而不是去找理由。不要只說做不到；解釋一下都能做些什么。

3 軟件的熵 6

提示5：不要放任破窗 7

只要看到不好的設計、錯誤的決策、糟糕的代碼，就趕緊去糾正。

4 石頭做的湯和煮熟的青蛙 9

提示6：做推動變革的催化劑 10

你無法強迫人們去改變，但可以展示美好未來，并幫助他們參與創(chuàng)造。

提示7：牢記全景 10

不要過度沉浸于細枝末節(jié)，以免察覺不到周圍正在發(fā)生的事情。

5 夠好即可的軟件 11

提示8：將質量要求視為需求問題 12

讓用戶參與對項目真實質量需求的確定。

6 知識組合 14

提示9：對知識組合做定期投資 16

養(yǎng)成學習的習慣。

提示10：批判性地分析你讀到和聽到的東西 18

不要受供應商、媒體炒作或教條的影響，根據(jù)自身和項目的實際情況來分析信息。

7 交流！ 20

提示11：英語就是另一門編程語言 20

將英語視作一門編程語言。寫文檔和編程一樣要遵循 DRY 原則、ETC、自動化等。

提示12：說什么和怎么說同樣重要 23

如果無法有效交流，任何偉大的想法都是沒有意義的。

提示13：把文檔嵌進去，而不要栓在表面 24

與代碼隔離的文檔，很難保持正確并及時更新。

第2章 務實的方法 27

8 優(yōu)秀設計的精髓 28

提示14：優(yōu)秀的設計比糟糕的設計更容易變更 28

適合使用者的事物，都已經(jīng)過良好設計。對代碼來說，這意味著必須適應變化。

9 DRY——邪惡的重復 30

提示15：DRY——不要重復自己 31

系統(tǒng)中的每一條知識，都必須有單一且無歧義的權威陳述。

提示16：讓復用變得更容易 39

只要復用方便，人們就會去做。創(chuàng)建一個支持復用的環(huán)境。

10 正交性 40

提示17：消除不相關事物之間的影響 41

設計的組件，需要自成一體、獨立自主，有單一的清晰定義的意圖。

11 可逆性 48

提示18：不設最終決定 50

不要把決定刻在石頭上，而要將其視為寫在沙灘上的東西，時刻準備應變。

提示19：放棄追逐時尚 50

尼爾·福特說過：“昨日之最佳實踐，即明日之反模式?！币诨驹瓌t去選擇架構，而不應盲從于流行。

12 曳光彈 51

提示20：使用曳光彈找到目標 53

通過不斷嘗試并看清著彈點，曳光彈可確保你最終擊中目標。

13 原型與便簽 57

提示21：用原型學習 58

制作原型旨在學習經(jīng)驗，其價值不在于過程中產生的代碼，而在于得到的教訓。

14 領域語言 60

提示22：靠近問題域編程 61

用問題領域的語言來做設計和編程。

15 估算 67

提示23：通過估算來避免意外 67

開始之前做估算，能提前發(fā)現(xiàn)潛在問題。

提示24：根據(jù)代碼不斷迭代進度表 72

利用實施過程中獲得的經(jīng)驗來精細化項目的時間尺度。

第3章 基礎工具 74

16 純文本的威力 75

提示25：將知識用純文本保存 76

純文本不會過時。它能夠讓你的工作事半功倍，并能簡化調試和測試工作。

17 Shell游戲 79

提示26：發(fā)揮 Shell 命令的威力 80

當圖形化界面無法勝任時，使用 Shell。

18 加強編輯能力 82

提示27：游刃有余地使用編輯器 82

既然編輯器是至關重要的工具，不妨了解一下如何用它更快更準確地實現(xiàn)需求。

19 版本控制 85

提示28：永遠使用版本控制 87

版本控制為你的工作創(chuàng)造了一個時間機器，可以用它重返過去。

20 調試 90

提示29：去解決問題，而不是責備 91

Bug 到底來自你的失誤還是別人的失誤真的不重要——它終究是你的問題，需要你來修復。

提示30：不要恐慌 91

不管是對銀河系搭車客，還是對開發(fā)者來說，都應這樣。

提示31：修代碼前先讓代碼在測試中失敗 93

在你修 Bug 前，先創(chuàng)建一個聚焦于該 Bug 的測試。

提示32：讀一下那些該死的出錯信息 93

大多數(shù)異常都能告訴失敗之物與失敗之處。如果足夠幸運，你甚至能得到具體的參數(shù)值。

提示33：“select”沒出問題 97

在操作系統(tǒng)或編譯器中發(fā)現(xiàn) Bug 非常罕見，甚至在第三方產品或庫中也是如此。Bug 大多出現(xiàn)在應用程序中。

提示34：不要假設，要證明 97

在真實環(huán)境中證實你的假設——要依賴真實的數(shù)據(jù)及邊界條件。

21 文本處理 99

提示35：學習一門文本處理語言 99

既然每天都要花大量的時間與文本打交道，何不讓計算機幫你分擔一二？

22 工程日記 101

第4章 務實的偏執(zhí) 103

提示36：你無法寫出完美的軟件 103

軟件不可能是完美的。對于在所難免的錯誤，要保護代碼和用戶免受其影響。

23 契約式設計 104

提示37：通過契約進行設計 107

代碼是否不多不少剛好完成它宣稱要做的事情，可以使用契約加以校驗和文檔化。

24 死掉的程序不會說謊 113

提示38：盡早崩潰 114

徹底死掉的程序通常比有缺陷的程序造成的損害要小。

25 斷言式編程 115

提示39：使用斷言去預防不可能的事情 115

如果一件事情不可能發(fā)生，那么就用斷言來確保其的確不會發(fā)生。斷言在校驗你的假設，要使用斷言在不確定的世界中將你的代碼保護起來。

26 如何保持資源的平衡 119

提示40：有始有終 119

只要有可能，對資源進行分配的函數(shù)或對象就有責任去釋放該資源。

提示41：在局部行動 122

將易變的變量維持在一個范圍內，打開資源的過程要短暫且明顯可見。

27 不要沖出前燈范圍 127

提示42：小步前進——由始至終 127

永遠小步前進，不斷檢查反饋，并且在推進前先做調整。

提示43：避免占卜 129

只在你能看到的范圍內做計劃。

第5章 寧彎不折 130

28 解耦 131

提示44：解耦代碼讓改變更容易 132

耦合使事物緊緊綁定在一起，以至于很難只改變其中之一。

提示45：只管命令不要詢問 133

不要從對象中取出值，在加以變換后再塞回去，讓對象自己來完成這些工作。

提示46：不要鏈式調用方法 135

當訪問某事物時，使用的點號不要超過一個。

提示47：避免全局數(shù)據(jù) 137

最好給每個方法增加一個額外的參數(shù)。

提示48：如果全局唯一非常重要，那么將它包裝到API 中 137

……但是，僅限于你真的非常希望它是全局的。

29 在現(xiàn)實世界中拋球雜耍 139

30 變換式編程 149

提示49：編程講的是代碼，而程序談的是數(shù)據(jù) 151

所有的程序都在變換數(shù)據(jù)——將輸入轉換為輸出。開始用變換式方法來設計吧！

提示50：不要囤積狀態(tài)，傳遞下去 156

不要把數(shù)據(jù)保持在函數(shù)或模塊的內部，拿出來傳遞下去。

31 繼承稅 162

提示51：不要付繼承稅 165

考慮一下能更好滿足需求的替代方案，比如接口、委托或mixin。

提示52：盡量用接口來表達多態(tài) 167

無需繼承引入的耦合，接口就能明確描述多態(tài)性。

提示53：用委托提供服務：“有一個”勝過“是一個” 167

不要從服務中繼承，應該包含服務。

提示54：利用 mixin 共享功能 169

mixin 不必承擔繼承稅就可以給類添加功能，而與接口結合可以讓多態(tài)不再令人痛苦。

32 配置 170

提示55：使用外部配置參數(shù)化應用程序 170

如果代碼對一些在應用程序發(fā)布后還有可能改變的值有所依賴，那么就在應用外部維護這些值。

第6章 并發(fā) 174

33 打破時域耦合 175

提示56：通過分析工作流來提高并發(fā)性 176

利用用戶工作流中的并發(fā)性。

34 共享狀態(tài)是不正確的狀態(tài) 179

提示57：共享狀態(tài)是不正確的狀態(tài) 180

共享狀態(tài)會帶來無窮的麻煩，而且往往只有重啟才能解決。

提示58：隨機故障通常是并發(fā)問題 186

或許時間和上下文的變化能暴露并發(fā)Bug，但并發(fā)Bug無法始終保持一致，也很難重現(xiàn)。

35 角色與進程 187

提示59：用角色實現(xiàn)并發(fā)性時不必共享狀態(tài) 188

使用角色來管理并發(fā)狀態(tài)，可以避免顯式的同步。

36 黑板 193

提示60：使用黑板來協(xié)調工作流 195

使用黑板來協(xié)調不相關的事實和代理人，能同時保持參與者之間的獨立性和孤立性。

第7章 當你編碼時 198

37 聽從蜥蜴腦 199

提示61：傾聽你內心的蜥蜴 201

當編程舉步維艱時，其實是潛意識在告訴你有什么地方不對勁。

38 巧合式編程 204

提示62：不要依賴巧合編程 207

只能依賴可靠的事物。注意偶然事件的復雜性，不要混淆快樂的巧合與有目的的計劃。

39 算法速度 210

提示63：評估算法的級別 214

在開始編程前，對這件事情大概會花多長時間要有概念。

提示64：對估算做測試 214

針對算法的數(shù)學分析無法說明所有問題，嘗試在目標環(huán)境中測試一下執(zhí)行代碼的耗時。

40 重構 216

提示65：盡早重構，經(jīng)常重構 219

像除草和翻整花園那樣，只要有需要就對代碼進行重新編寫、修訂和架構，以便找到問題的根源并加以修復。

41 為編碼測試 220

提示66：測試與找 Bug 無關 221

測試是觀察代碼的一個視角，可以從中得到針對設計、接口和耦合度的反饋。

提示67：測試是代碼的第一個用戶 222

用測試的反饋來引導工作。

提示68：既非自上而下，也不自下而上，基于端對端構建 225

創(chuàng)建一小塊端到端的功能，從中獲悉問題之所在。

提示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

軟件開發(fā)更像是一種由用戶和程序員協(xié)同創(chuàng)造的行為。

提示77：需求是從反饋循環(huán)中學到的 254

理解需求需要探索和反饋，因此決策的結果可以用來完善最初的想法。

提示78：和用戶一起工作以便從用戶角度思考 255

這是看透系統(tǒng)將如何被真正使用的最佳方法。

提示79：策略即元數(shù)據(jù) 256

不要將策略硬編碼進系統(tǒng)，而應該將其表達為系統(tǒng)的一組元數(shù)據(jù)。

提示80：使用項目術語表 259

為項目的所有特定詞匯創(chuàng)建一張術語表，并且在單一源頭維護。

46 處理無法解決的難題 260

提示81：不要跳出框框思考——找到框框 261

在面對無法解決的難題時，識別出真正的約束?？梢詥栕约海骸氨仨氝@樣做才能搞定嗎？必須搞定它嗎？”

47 攜手共建 264

提示82：不要一個人埋頭鉆進代碼中 267

編程往往困難又費力，找個朋友和你一起干。

提示83：敏捷不是一個名詞；敏捷有關你如何做事 267

敏捷是一個形容詞，有關如何做事情。

48 敏捷的本質 267

第9章 務實的項目 271

49 務實的團隊 272

提示84：維持小而穩(wěn)定的團隊 272

團隊應保持穩(wěn)定、小巧，團隊中的每個人都應相互信任、互相依賴。

提示85：排上日程以待其成 274

如果你不把事情納入日程表，它們就不會發(fā)生。反思、實驗、學習、提高技能，這些事都應放入日程表。

提示86：組織全功能的團隊 276

圍繞功能而不是工作職能組織團隊。不要將 UI/UX 設計者從程序員中分離出去，也不要分開前端和后端；不要區(qū)分數(shù)據(jù)建模者和測試人員，以及開發(fā)和設計。構建一個團隊，這樣你就可以漸進地不斷迭代端到端的代碼。

50 椰子派不上用場 277

提示87：做能起作用的事，別趕時髦 279

不要僅僅因為別的公司正在那么干就采納一項技術或采用一個開發(fā)方法，而是要采用自己所處環(huán)境中對團隊有效的東西。

提示88：在用戶需要時交付 281

不要卡著流程要求，刻意等到幾周甚至幾個月后才交付。

51 務實的入門套件 281

提示89：使用版本控制來驅動構建、測試和發(fā)布 282

利用提交或推送來觸發(fā)構建、測試、發(fā)布，利用版本控制的標簽來進行生產部署。

提示90：盡早測試，經(jīng)常測試，自動測試 283

每次構建都跑一下的測試，要比束之高閣的測試計劃有效得多。

提示91：直到所有的測試都已運行，編碼才算完成 283

無須多言。

提示92：使用破壞者檢測你的測試 285

在一個單獨的源碼副本中特意引入 Bug，驗證測試能否將其捕獲。

提示93：測試狀態(tài)覆蓋率，而非代碼覆蓋率 286

要識別并測試重要的程序狀態(tài)，只測試一行行的代碼是不夠的。

提示94：每個 Bug 只找一次 286

只要人類測試者找到一個 Bug ，就應該是該 Bug 最后一次被人類發(fā)現(xiàn)。從此之后，自動化測試完全可以發(fā)現(xiàn)它。

提示95：不要使用手動程序 287

計算機能一次又一次，按照同樣的次序，執(zhí)行相同的指令。

52 取悅用戶 288

提示96：取悅用戶，而不要只是交付代碼 289

為用戶開發(fā)能夠帶來商業(yè)價值的解決方案，并讓他們每天都感到愉快。

提示97：在作品上簽名 290

過去的工匠在為他們的作品簽名時非常自豪，你也應該這樣。

53 傲慢與偏見 290

跋 292

提示98：先勿傷害 293

犯錯在所難免，確保犯錯后沒人會因此受難。

提示99：不要助紂為虐 294

因為這樣做你也有變成紂王的風險。

參考文獻 295

練習的參考答案 297

譯者跋 312

精彩書摘

序

我還記得 Dave 和 Andy 第一次在推特上談論這本書的新版的那一刻——這可是一條大新聞。在編程社區(qū)，所見之處都是對這條大新聞興奮的回應，人們的期待塞滿了我的信息流。二十年過去了，《程序員修煉之道》這本書的地位不遜于當年。

承載這樣一段歷史的一本書，能引起這樣的反響，本身就說明了很多問題。為了寫這篇序，我有幸在尚未出版前閱讀了本書，讀后我就明白了它為什么會引起這么大的轟動。本來，一本書被冠以技術圖書之名，給人的印象應該是不太好的。因為技術圖書常常令人生畏——充斥著深奧的詞匯、晦澀的術語和令人費解的例子，不經(jīng)意間就會讓你覺得自己很愚蠢。而且，作者越有經(jīng)驗，就越容易忘記初學者在學習新概念時的感覺。

Dave 和 Andy 的作品，卻能透出那種只有剛剛學到這些課程的人才會有的興奮感，盡管他們已有幾十年的編程經(jīng)驗，卻戰(zhàn)勝了寫出這種感覺的挑戰(zhàn)。他們不會居高臨下地指指點點，不會假定你是個專家，甚至不認為你已讀過本書第一版，僅僅把你當成想要變得更好的程序員而已。他們不惜用整本書的篇幅來幫助你達到目標，一步一個腳印。

公平地說，在這方面，他們在過往已經(jīng)成績斐然。最初的本書第一版，包含了許多具體的例子、新想法和實用的技巧，可以幫助你修煉編程所需的“肌肉”和“大腦”，這些東西到今天仍然適用。但是，這次在新版圖書中，又有了兩項改進。

第一項顯而易見：刪除了一些較老的引用內容和過時的例子，增補了大量新鮮、現(xiàn)代的內容。循環(huán)不變式或構建機這樣的例子已經(jīng)看不到了。Dave 和 Andy 保留了第一版書中的重要內容，以確保相應的課程依然有效，而且讀者也不必受舊示例的干擾。對于像 DRY（不要重復自己）這樣的舊思想，上面的灰塵已被撣去，并且涂上了一層新油漆——這樣做真的讓其熠熠生輝。

而第二項，才是這次新版圖書發(fā)布真正令人興奮的地方。在寫完本書第一版后，他們有機會思考自己想要說什么，想讓讀者獲得什么，以及讀者是如何接受這些信息的。他們得到了這些課程的反饋，也看到了讀者在哪里被卡住、有什么需要改進，以及哪些內容被誤解。在這本書通過全世界程序員的雙手和心靈傳播的二十年間，Dave 和 Andy 研究了這些回應，并且形成了新的想法和理念。

他們認識到自主權的重要性，并且意識到，相比大多數(shù)其他專業(yè)人員，開發(fā)者或許更能為自己做主。他們以簡單而深刻的啟示開始這本書：“人生是你的?！边@喚起了我們自己的力量，它就蘊含在我們的代碼庫、工作和職業(yè)生涯中。這也為本書的其他內容定下了基調——它不僅僅是又一本充滿代碼示例的技術圖書。

這本書必定會在擺滿各種技術圖書的書架上脫穎而出，因為它理解身為一名程序員到底意味著什么。編程關涉諸事——盡量減少未來的痛苦，讓隊友更輕松，做錯事情后能夠重新振作起來，養(yǎng)成良好的習慣，以及理解工具集。編程只是程序員世界的一部分，而這本書探索了整個世界。

我在思考編碼之旅上花了很多時間。我不是從小就開始接觸編程的，大學里也沒學過編程課?？梢哉f，我的青少年時光并沒有花在“擺弄”科技上，直到二十來歲的時候才進入了編程的世界，因而亟須想明白一件事情：成為一名程序員意味著什么。編程社區(qū)與我曾經(jīng)身處的其他社區(qū)非常不同。其獨特之處在于，人們無不醉心于學習和實踐，這既令人生畏，又讓人耳目一新。

這對我來說，真像進入一個全新的世界。就算去到一個新城鎮(zhèn)，也有必要了解鄰居、挑選雜貨店、找到最好的咖啡店。我花了一段時間來了解地形，找到了最有效的路線，避開了交通最繁忙的街道，并且知道了什么時候交通可能會出問題。等到天氣變化，我又要去置辦應季的新衣。

來到一個新城鎮(zhèn)的頭幾周，甚至是頭幾個月，可能會很害怕。如果有一個已經(jīng)在這里住了一段時間的鄰居，而且他知識淵博又友好，那不是再好不過的事情嗎？誰能帶你四處參觀，誰能領你去那些咖啡店？當然是一個在當?shù)卮俗銐蜷L時間的，了解當?shù)匚幕?、當?shù)孛}搏的人。這樣你不僅有家的感覺，還能成為一個同樣有貢獻的成員。Dave 和 Andy 就是這樣的鄰居。

一個準新人，更容易對成為程序員的過程，而不是對編程的行為不知所措。因此，必須對整個心態(tài)做一次切換——改變習慣、行為和期望。僅僅知道如何編程，并不會讓你成為一名更好的程序員，在這個過程中必須經(jīng)歷有意識和深思熟慮的實踐。好在現(xiàn)在有了這本書，可以有效地指導你成為更好的程序員。

但不要搞錯了——這本書不會告訴你編程應該是怎樣的，它并沒有使用那種哲學或審判的方式，它只是簡單、明了地告訴你，什么是務實的程序員——他們如何操作、如何處理代碼。作者讓你自己決定是否想成為其中的一員。如果你覺得不適合，也沒有人會怪罪你。但如果你決定成為其中的一員，作者就是你的友好鄰居，會陪伴左右、為你指路。

Saron Yitbarek

CodeNewbie 創(chuàng)始人及 CEOCommand Line Heroes 主辦者

前言/序言

新版前言

在20世紀90年代，我們在與一些項目存在問題的公司合作時，發(fā)現(xiàn)總是在對每個人說同樣的話：也許你應該在發(fā)布之前先測試一下。為什么代碼只能在 Mary 的機器上構建？為什么沒有人問一下用戶呢？

為了節(jié)省與新客戶打交道的時間，我們開始做筆記。這些筆記最終變成了《程序員修煉之道》這本書。令人驚訝的是，這本書似乎引起了大家的共鳴，在過去的二十年間，這本書一直很受歡迎。

但是二十年對于軟件領域來說已經(jīng)過了好幾代。如果一個開發(fā)者從 1999 年直接穿越到今天的團隊中，面對這個陌生的新世界一定會備感掙扎。但20世紀90年代的世界對今天的開發(fā)者來說同樣陌生。書中所引用的 CORBA、CASE 工具，以及索引、循環(huán)這些東西，放在今天，充其量不過略顯古雅有趣，而更多的會給人帶來困擾。

與此同時，二十年對常識沒有絲毫影響。技術可能改變了，但人沒有。實踐和方法中的閃光點，在今天看來光芒依舊。在這些方面，本書保鮮如初。

所以，當我們要出版這本二十周年紀念版的時候，必須做出抉擇——是回顧和更新前一版中引用的技術后就大功告成，還是充分借鑒這平添的二十年豐富經(jīng)驗，重新審視前一版所推崇的實踐背后的種種假設。

最終，我們兩者都做了。

因此，這本書有點像忒修斯之船。書中大約三分之一的主題是全新的，而其余的大部分都被部分或全部重寫了。我們的目的是，讓內容變得更清晰、更貼切，并在某種程度上不受時間的影響。

我們做了一些艱難的決定。刪除了參考資料附錄，這樣做既因為它無法持續(xù)更新，也因為當你有此需要時很容易就能搜索獲得。我們重新組織了與并發(fā)有關的主題，這是因為考慮到當前有著大量的并行硬件，卻缺乏處理并行的好方法。我們還添加了一些內容來反映不斷變化的認知和環(huán)境，從我們幫助發(fā)起的敏捷運動，到對函數(shù)式編程語境的日益接受，再到對隱私和安全性方面日益增長的需求。

然而有趣的是，我們之間關于版本內容的爭論比寫第一個版本時要少得多。重要的東西更容易辨別，這已是我們的共識。

無論如何，這本書最后就是這個樣子了，請享用吧。你也許可以從中吸取一些新的做法，也許會覺得我們建議的某些東西是錯的，不妨把它們都帶到你的工作中去，然后給我們反饋。

但是，最重要的是，記住過程要開心。

這本書是如何組織的

這本書是許多短小主題的合集。每一個主題都針對特定的話題而獨立成章。你會發(fā)現(xiàn)大量的交叉引用，這有助于把各個主題連貫起來。你可以以任意次序隨意閱讀這些主題——這不是一本需要從頭到尾閱讀的書。

偶爾你會看到一個寫有提示n的框起來的標簽塊（比如位于第XVII頁的提示1：關注你的技藝）。這些提示不僅是文中的重點，在我們眼里也是一條條生命——我們每天都賴以為生。

我們已盡可能適時地在書中加入了練習和挑戰(zhàn)。練習通常有相對簡單的答案，而挑戰(zhàn)則更加開放。為了讓你理解我們的思維方式，在附錄里我們列出了這些練習的答案，但是擁有唯一正確答案的問題并不多。挑戰(zhàn)或許能用于高級編程課程中的小組討論，或許能作為論文寫作的基礎。

本書還有一個簡短的參考文獻，列出了我們明確引用的圖書和文章。

名字有什么含義

“我用一個詞，”矮胖子相當傲慢地說，“總是同我想要說的恰如其分的，既不重，也不輕?！?/p>

—— 路易斯·卡羅《愛麗絲鏡中奇遇》

在整本書中，你會發(fā)現(xiàn)各種各樣的行話——要么原本是完好的英語單詞，卻被曲解為技術詞，要么是一些可怕的合成詞，由那些對語言充滿怨恨的計算機科學家賦予其意義。當我們第一次使用這些行話時，會嘗試定義它們，或者至少對其含義給出解釋。當然，肯定還有漏網(wǎng)之魚，而且像對象和關系型數(shù)據(jù)庫這種已被廣泛使用的，再下一次定義就有點畫蛇添足了。如果你遇到一個以前沒見過的術語，請不要跳過它，不妨花點時間去查一下，可以在網(wǎng)上查，也可以在計算機科學的課本上查。如果有機會還可以給我們發(fā)郵件投訴，這樣我們就可以在本書下一版中增加一個定義。

既然話已至此，我們決定報復一下計算機科學家。有時候，明明有一些非常好的術語，對某個概念表達得很好，但我們卻決定不使用這些術語。為什么？因為現(xiàn)有的術語通常局限于特定的問題領域，或者特定的開發(fā)階段。而本書的基本哲學之一就是，我們推薦的大多數(shù)技術都是通用的：例如模塊化，它就能同時適用于代碼、設計、文檔和團隊組織。當某個傳統(tǒng)術語被拿來在更廣泛的場景下使用時，卻會造成困惑——我們似乎無法擺脫該術語從最初就開始背負的歷史包袱。當這種情況發(fā)生時，我們只好發(fā)明自己的術語，助紂為虐地讓語言繼續(xù)墮落。

源碼與其他資源

本書中的大部分代碼都是從可編譯的源文件中提取出來的，這些源文件可以從我們的網(wǎng)站上下載。

在那里，你還可以找到我們認為有用的資源鏈接、本書的更新內容，以及其他有關《程序員修煉之道》項目進展的新聞。

給我們反饋

收到你的來信我們會很高興。我們的電子郵件地址是 ppbook@pragprog.com。

第二版鳴謝

在過去的二十年里，有成千上萬關于編程的有趣對話曾讓我們開心不已，其中不乏在會議、課程，甚至是飛機上與人們的偶遇。每一次經(jīng)歷，都會加深我們對開發(fā)過程的理解，并為此版本的更新添磚加瓦。感謝所有人（而且，當我們犯錯誤的時候，請繼續(xù)提醒）。

感謝本書 Beta 測試過程的參與者，是你們的問題和評論，幫助我們把事情解釋得更清楚。

在進行 Beta 測試之前，我們曾與一些人分享過本書。感謝 VM (Vicky) Brasseur、 Jeff Langr、 Kim Shrier 給予的詳細評論，感謝 José Valim 與 Nick Cuthbert 的技術審核。

感謝 Ron Jeffries 讓我們用數(shù)獨的例子。

非常感謝培生集團的人，是他們讓我們以自己的方式來創(chuàng)作這本書。

特別感謝不可或缺的 Janet Furlow，她掌控著一切，讓我們的工作沒有走樣。

最后，向所有在過去的二十年里一直致力于讓編程變得更好的務實的程序員們發(fā)出一聲吶喊：再接再厲，更創(chuàng)二十年輝煌。

點此購買