你見過的最差的程式員是怎樣的？

糟糕的代碼

20世紀80年代末，有家公司寫了個很流行的殺手應用，許多專業人士都買來用，然后，發布周期開始拉長，缺陷總是不能修復，裝載時間越來越久，崩潰的幾率也越來越大，至今我還記得自己在某天沮喪地關掉那個程式，從此再不用它，在那之后不久，該公司就關門大吉了，

20年后，我見到那家公司的一位早期雇員，問他當年發生了什么事，他的回答叫我愈發恐懼起來，原來，當時他們趕著推出產品，代碼寫得亂七八糟，特性越加越多，代碼也越來越爛，最后再也沒法管理這些代碼了，是糟糕的代碼毀了這家公司，

你是否曾為糟糕的代碼所深深困擾？如果你是位有點兒經驗的程式員，定然多次遇到過這類困境，我們有專用來形容這事的詞：沼澤（wading），我們趟過代碼的水域，我們穿過灌木密布、瀑布暗藏的沼澤地，我們拼命想找到出路，期望有點什么線索能啟發我們到底發生了什么事；但目光所及，只是越來越多死氣沉沉的代碼，

你當然曾為糟糕的代碼所困擾過，那么——為什么要寫糟糕的代碼呢？

是想快點完成嗎？是要趕時間嗎？有可能，或許你覺得自己要干好所需的時間不夠；假使花時間清理代碼，老板就會大發雷霆，或許你只是不耐煩再搞這套程式，期望早點結束，或許你看了看自己承諾要做的其他事，意識到得趕緊弄完手上的東西，好接著做下一件作業，這種事我們都干過，

我們都曾經瞟一眼自己親手造成的混亂，決定棄之而不顧，走向新一天，我們都曾經看到自己的爛程式居然能運行，然后斷言能運行的爛程式總比什么都沒有強，我們都曾經說過有朝一日再回頭清理，當然，在那些日子里，我們都沒聽過勒布朗（LeBlanc）法則：稍后等于永不（Later equals never），

混亂的代價

只要你干過兩三年編程，就有可能曾被某人的糟糕的代碼絆倒過，如果你編程不止兩三年，也有可能被這種代碼拖過后腿，進度延緩的程度會很嚴重，有些團隊在專案初期進展迅速，但有那么一兩年的時間卻慢如蝸行，對代碼的每次修改都影響到其他兩三處代碼，修改無小事，每次添加或修改代碼，都得對那堆扭紋柴了然于心，這樣才能往上扔更多的扭紋柴，這團亂麻越來越大，再也無法理清，最后束手無策，

隨著混亂的增加，團隊生產力也持續下降，趨向于零，當生產力下降時，管理層就只有一件事可做了：增加更多人手到專案中，期望提升生產力，可是新人并不熟悉系統的設計，他們搞不清楚什么樣的修改符合設計意圖，什么樣的修改違背設計意圖，而且，他們以及團隊中的其他人都背負著提升生產力的可怕壓力，于是，他們制造更多的混亂，驅動生產力向零那端不斷下降，如圖1-1所示，

圖1-1　生產力vs.時間

1　華麗新設計

最后，開發團隊造反了，他們告訴管理層，再也無法在這令人生厭的代碼基礎上做開發，他們要求做全新的設計，管理層不愿意投入資源完全重啟爐灶，但他們也不能否認生產力低得可怕，他們只好同意開發者的要求，授權去做一套看上去很美的華麗新設計，

于是就組建了一支新軍，誰都想加入這個團隊，因為它是張白紙，他們可以重新來過，搞出點真正漂亮的東西來，但只有最優秀、最聰明的家伙被選中，其余人等則繼續維護現有系統，

現在有兩支隊伍在競賽了，新團隊必須搭建一套新系統，要能實作舊系統的所有功能，另外，還得跟上對舊系統的持續改動，在新系統功能足以抗衡舊系統之前，管理層不會替換掉舊系統，

競賽可能會持續極長時間，我就見過延續了十年之久的，到了完成的時候，新團隊的老成員早已不知去向，而現有成員則要求重新設計一套新系統，因為這套系統太爛了，

假使你經歷過哪怕是一小段我談到的這種事，那么你一定知道，花時間保持代碼整潔不但有關效率，還有關生存，

2　態度

你是否遇到過某種嚴重到要花數個星期來做本來只需數小時即可完成的事的混亂狀況？你是否見過本來只需做一行修改，結果卻涉及上百個模塊的情況？這種事太常見了，

怎么會發生這種事？為什么好代碼會這么快就變質成糟糕的代碼？理由多得很，我們抱怨需求變化背離了初期設計，我們哀嘆進度太緊張，沒法干好活，我們把問題歸咎于那些愚蠢的經理、苛求的用戶、沒用的營銷方式和那些電話消毒劑，不過，親愛的呆伯特（Dilbert），我們是自作自受，我們太不專業了，

這話可不太中聽，怎么會是自作自受呢？難道不關需求的事？難道不關進度的事？難道不關那些蠢經理和沒用的營銷手段的事？難道他們就不該負點責嗎？

不，經理和營銷人員指望從我們這里得到必須的資訊，然后才能做出承諾和保證；即便他們沒開口問，我們也不該羞于告知自己的想法，用戶指望我們驗證需求是否都在系統中實作了，專案經理指望我們遵守進度，我們與專案的規劃脫不了干系，對失敗負有極大的責任；特別是當失敗與糟糕的代碼有關時尤為如此！

“且慢！”你說，“不聽經理的，我就會被炒魷魚，”多半不會，多數經理想要知道實情，即便他們看起來不喜歡實情，多數經理想要好代碼，即便他們總是癡纏于進度，他們會奮力衛護進度和需求；那是他們該干的，你則當以同等的熱情衛護代碼，

再說明白些，假使你是位醫生，病人請求你在給他做手術前別洗手，因為那會花太多時間，你會照辦嗎[4]？本該是病人說了算；但醫生卻絕對應該拒絕遵從，為什么？因為醫生比病人更了解疾病和感染的風險，醫生如果按病人說的辦，就是一種不專業的態度（更別說是犯罪了），

同理，程式員遵從不了解混亂風險的經理的意愿，也是不專業的做法，

3　迷題

程式員面臨著一種基礎價值謎題，有那么幾年經驗的開發者都知道，之前的混亂拖了自己的后腿，但開發者們背負期限的壓力，只好制造混亂，簡言之，他們沒花時間讓自己做得更快！

真正的專業人士明白，這道謎題的第二部分說錯了，制造混亂無助于趕上期限，混亂只會立刻拖慢你，叫你錯過期限，趕上期限的唯一方法——做得快的唯一方法 ——就是始終盡可能保持代碼整潔，

做一個優秀的程式員，你一定要讀一讀《代碼整潔之道》

學寫整潔代碼很難，它可不止于要求你掌握原則和模式，你得在這上面花工夫，你須自行實踐，且體驗自己的失敗，你須觀察他人的實踐與失敗，你須看看別人是怎樣蹣跚學步，再轉頭研究他們的路數，你須看看別人是如何絞盡腦汁做出決策，又是如何為錯誤決策付出代價，

閱讀本書要多用心思，這可不是那種降落前就能讀完的“感覺不錯”的飛機書，本書要讓你用功，而且是非常用功，如何用功？閱讀代碼——大量代碼，而且你要去琢磨某段代碼好在什么地方、壞在什么地方，在我們分解，而后組合模塊時，你得亦步亦趨地跟上，這得花些工夫，不過值得一試，

本書大致可分為3個部分，前幾章介紹撰寫整潔代碼的原則、模式和實踐，這部分有相當多的示例代碼，讀起來頗具挑戰性，讀完這幾章，就為閱讀第2部分做好了準備，如果你就此止步，只能祝你好運啦！

第2部分最需要花工夫，這部分包括幾個復雜性不斷增加的案例研究，每個案例都清理一些代碼——把有問題的代碼轉化為問題少一些的代碼，這部分極為詳細，你的思維要在講解和代碼段之間跳來跳去，你得分析和理解那些代碼，琢磨每次修改的來龍去脈，

你付出的勞動將在第3部分得到回報，這部分只有一章，列出從上述案例研究中得到的啟示和靈感，在遍覽和清理案例中的代碼時，我們把每個操作理由記錄為一種啟示或靈感，我們嘗試去理解自己對閱讀和修改代碼的反應，盡力了解為什么會有這樣的感受、為什么會如此行事，結果得到了一套描述在撰寫、閱讀、清理代碼時思維方式的知識庫，

如果你在閱讀第2部分的案例研究時沒有好好用功，那么這套知識庫對你來說可能所值無幾，在這些案例研究中，每次修改都仔細注明了相關啟示的標號，這些標號用方括號標出，如：[H22]，由此你可以看到這些啟示在何種環境下被應用和撰寫，啟示本身不值錢，啟示與案例研究中清理代碼的具體決策之間的關系才有價值，

如果你跳過案例研究部分，只閱讀了第1部分和第3部分，那就不過是又看了一本關于寫出好軟體的“感覺不錯”的書，但如果你肯花時間琢磨那些案例，亦步亦趨——站在作者的角度，迫使自己以作者的思維路徑考慮問題，就能更深刻地理解這些原則、模式、實踐和啟示，這樣的話，就像一個熟練地掌握了騎車的技術后，自行車就如同其身體的延伸部分那樣；對你來說，本書所介紹的整潔代碼的原則、模式、實踐和啟示就成為了本身具有的技藝，而不再是“感覺不錯”的知識，