摘錄自《代碼整潔之道》不過改了幾處表達方式。
[color=red][b]代碼可以有，代碼必須有[/b][/color]
有人也許會以爲，關於代碼的書有點兒落後於時代-代碼不再是問題；我們應當關注模型和需求。確實，有人說過我們正在臨近代碼的終結點。很快，代碼就會自動產生出來，不需要再人工編寫。程序員完全沒用了，因爲商務人士可以從規約直接生成程序。
扯淡！我們永遠拋不掉代碼，因爲代碼呈現了需求的細節。在某些層面上，這些細節無法被忽略或抽象，必須明確之。將需求明確到機器可以執行的細節程度，就是編程要做的事。而這種規約正是代碼。
我期望語言的抽象程度繼續提升。我也期望領域特定語言的數量繼續增加。那會是好事一樁。但那終結不了代碼。實際上，在較高層次上用領域特定語言撰寫的規約也將是代碼！它也得嚴謹、精確、規範和詳細，好讓機器理解和執行。
那幫以爲代碼終將消失的夥計，就像是巴望着發現一種無規範數學的數學家們一般。他們巴望着，總有一天能創造出某種機器，我們只要想想、嘴都不用張就能叫它依計行事。那機器要能透徹理解我們，只有這樣，它才能把含糊不清的需求翻譯爲可完美執行的程序，精確滿足需求。
這種事永遠不會發生。即便是人類，傾其全部的直覺和創造力，也造不出滿足客戶模糊感覺的成功系統來。如果說需求規約原則教給了我們什麼，那就是歸置良好的需求就像代碼一樣正式，也能作爲代碼的可執行測試來使用。
記住，代碼確然是我們最終用來表達需求的那種語言。我們可以創造各種與需求接近的語言。我們可以創造幫助把需求解析和彙整爲正式結構的各種工具。然而，我們永遠無法拋棄必要的精確性-所以代碼永存。
[color=red][b]代碼是怎麼被寫爛的[/b][/color]
最近我在讀Kent Beck著Implementation Patterns（中譯版《實現模式》） 一書的序言。他這樣寫道："……本書基於一種不太牢靠的前提：好代碼的確重要……"這前提不牢靠？我反對！我認爲這是該領域最強固、最受支持、最被強調的前提了（我想Kent也知道）。我們知道好代碼重要，是因爲其短缺實在困擾了我們太久。
20世紀80年代末，有家公司寫了個很流行的殺手應用，許多專業人士都買來用。然後，發佈週期開始拉長。缺陷總是不能修復。裝載時間越來越久，崩潰的機率也越來越大。至今我還記得自己在某天沮喪地關掉那個程序，從此再不用它。在那之後不久，該公司就關門大吉了。
20年後，我見到那家公司的一位早期僱員，問他當年發生了什麼事。他的回答叫我愈發恐懼起來。原來，當時他們趕着推出產品，代碼寫得亂七八糟。特性越加越多，代碼也越來越爛，最後再也沒法管理這些代碼了。是糟糕的代碼毀了這家公司。
你是否曾爲糟糕的代碼所深深困擾？如果你是位有點兒經驗的程序員，定然多次遇到過這類困境。我們有專用來形容這事的詞：沼澤（wading）。我們趟過代碼的水域。我們穿過灌木密佈、瀑布暗藏的沼澤地。我們拼命想找到出路，期望有點什麼線索能啓發我們到底發生了什麼事；但目光所及，只是越來越多死氣沉沉的代碼。
你當然曾爲糟糕的代碼所困擾過。那麼-爲什麼要寫糟糕的代碼呢？
是想快點完成嗎？是要趕時間嗎？有可能。或許你覺得自己要幹好所需的時間不夠；假使花時間清理代碼，老闆就會大發雷霆。或許你只是不耐煩再搞這套程序，期望早點結束。或許你看了看自己承諾要做的其他事，意識到得趕緊弄完手上的東西，好接着做下一件工作。這種事我們都幹過。
我們都曾經瞟一眼自己親手造成的混亂，決定棄之而不顧，走向新一天。我們都曾經看到自己的爛程序居然能運行，然後斷言能運行的爛程序總比什麼都沒有強。我們都曾經說過有朝一日再回頭清理。當然，在那些日子裏，我們都沒聽過勒布朗（LeBlanc）法則：稍後等於永不（Later equals never）。
[color=red][b]混亂的代價 == 揮刀自宮[/b][/color]
只要你幹過兩三年編程，就有可能曾被某人的糟糕的代碼絆倒過。如果你編程不止兩三年，也有可能被這種代碼拖過後腿。進度延緩的程度會很嚴重。有些團隊在項目初期進展迅速，但有那麼一兩年的時間卻慢如蝸行。對代碼的每次修改都影響到其他兩三處代碼。修改無小事。每次添加或修改代碼，都得對那堆扭紋柴瞭然於心，這樣才能往上扔更多的扭紋柴。這團亂麻越來越大，再也無法理清，最後束手無策。
隨着混亂的增加，團隊生產力也持續下降，趨向於零。當生產力下降時，管理層就只有一件事可做了：增加更多人手到項目中，期望提升生產力。可是新人並不熟悉系統的設計。他們搞不清楚什麼樣的修改符合設計意圖，什麼樣的修改違背設計意圖。而且，他們以及團隊中的其他人都揹負着提升生產力的可怕壓力。於是，他們製造更多的混亂，驅動生產力向零那端不斷下降。
[color=red][b]程序員起義[/b][/color]
最後，開發團隊造反了，他們告訴管理層，再也無法在這令人生厭的代碼基礎上做開發。他們要求做全新的設計。管理層不願意投入資源完全重啓爐竈，但他們也不能否認生產力低得可怕。他們只好同意開發者的要求，授權去做一套看上去很美的華麗新設計。
於是就組建了一支新軍。誰都想加入這個團隊，因爲它是張白紙。他們可以重新來過，搞出點真正漂亮的東西來。但只有最優秀、最聰明的傢伙被選中。其餘人等則繼續維護現有系統。
現在有兩支隊伍在競賽了。新團隊必須搭建一套新系統，要能實現舊系統的所有功能。另外，還得跟上對舊系統的持續改動。在新系統功能足以抗衡舊系統之前，管理層不會替換掉舊系統。
競賽可能會持續極長時間。我就見過延續了十年之久的。到了完成的時候，新團隊的老成員早已不知去向，而現有成員則要求重新設計一套新系統，因爲這套系統太爛了。
假使你經歷過哪怕是一小段我談到的這種事，那麼你一定知道，花時間保持代碼整潔不但有關效率，還有關生存。
[color=red][b]代碼可以有，代碼必須有[/b][/color]
有人也許會以爲，關於代碼的書有點兒落後於時代-代碼不再是問題；我們應當關注模型和需求。確實，有人說過我們正在臨近代碼的終結點。很快，代碼就會自動產生出來，不需要再人工編寫。程序員完全沒用了，因爲商務人士可以從規約直接生成程序。
扯淡！我們永遠拋不掉代碼，因爲代碼呈現了需求的細節。在某些層面上，這些細節無法被忽略或抽象，必須明確之。將需求明確到機器可以執行的細節程度，就是編程要做的事。而這種規約正是代碼。
我期望語言的抽象程度繼續提升。我也期望領域特定語言的數量繼續增加。那會是好事一樁。但那終結不了代碼。實際上，在較高層次上用領域特定語言撰寫的規約也將是代碼！它也得嚴謹、精確、規範和詳細，好讓機器理解和執行。
那幫以爲代碼終將消失的夥計，就像是巴望着發現一種無規範數學的數學家們一般。他們巴望着，總有一天能創造出某種機器，我們只要想想、嘴都不用張就能叫它依計行事。那機器要能透徹理解我們，只有這樣，它才能把含糊不清的需求翻譯爲可完美執行的程序，精確滿足需求。
這種事永遠不會發生。即便是人類，傾其全部的直覺和創造力，也造不出滿足客戶模糊感覺的成功系統來。如果說需求規約原則教給了我們什麼，那就是歸置良好的需求就像代碼一樣正式，也能作爲代碼的可執行測試來使用。
記住，代碼確然是我們最終用來表達需求的那種語言。我們可以創造各種與需求接近的語言。我們可以創造幫助把需求解析和彙整爲正式結構的各種工具。然而，我們永遠無法拋棄必要的精確性-所以代碼永存。
[color=red][b]代碼是怎麼被寫爛的[/b][/color]
最近我在讀Kent Beck著Implementation Patterns（中譯版《實現模式》） 一書的序言。他這樣寫道："……本書基於一種不太牢靠的前提：好代碼的確重要……"這前提不牢靠？我反對！我認爲這是該領域最強固、最受支持、最被強調的前提了（我想Kent也知道）。我們知道好代碼重要，是因爲其短缺實在困擾了我們太久。
20世紀80年代末，有家公司寫了個很流行的殺手應用，許多專業人士都買來用。然後，發佈週期開始拉長。缺陷總是不能修復。裝載時間越來越久，崩潰的機率也越來越大。至今我還記得自己在某天沮喪地關掉那個程序，從此再不用它。在那之後不久，該公司就關門大吉了。
20年後，我見到那家公司的一位早期僱員，問他當年發生了什麼事。他的回答叫我愈發恐懼起來。原來，當時他們趕着推出產品，代碼寫得亂七八糟。特性越加越多，代碼也越來越爛，最後再也沒法管理這些代碼了。是糟糕的代碼毀了這家公司。
你是否曾爲糟糕的代碼所深深困擾？如果你是位有點兒經驗的程序員，定然多次遇到過這類困境。我們有專用來形容這事的詞：沼澤（wading）。我們趟過代碼的水域。我們穿過灌木密佈、瀑布暗藏的沼澤地。我們拼命想找到出路，期望有點什麼線索能啓發我們到底發生了什麼事；但目光所及，只是越來越多死氣沉沉的代碼。
你當然曾爲糟糕的代碼所困擾過。那麼-爲什麼要寫糟糕的代碼呢？
是想快點完成嗎？是要趕時間嗎？有可能。或許你覺得自己要幹好所需的時間不夠；假使花時間清理代碼，老闆就會大發雷霆。或許你只是不耐煩再搞這套程序，期望早點結束。或許你看了看自己承諾要做的其他事，意識到得趕緊弄完手上的東西，好接着做下一件工作。這種事我們都幹過。
我們都曾經瞟一眼自己親手造成的混亂，決定棄之而不顧，走向新一天。我們都曾經看到自己的爛程序居然能運行，然後斷言能運行的爛程序總比什麼都沒有強。我們都曾經說過有朝一日再回頭清理。當然，在那些日子裏，我們都沒聽過勒布朗（LeBlanc）法則：稍後等於永不（Later equals never）。
[color=red][b]混亂的代價 == 揮刀自宮[/b][/color]
只要你幹過兩三年編程，就有可能曾被某人的糟糕的代碼絆倒過。如果你編程不止兩三年，也有可能被這種代碼拖過後腿。進度延緩的程度會很嚴重。有些團隊在項目初期進展迅速，但有那麼一兩年的時間卻慢如蝸行。對代碼的每次修改都影響到其他兩三處代碼。修改無小事。每次添加或修改代碼，都得對那堆扭紋柴瞭然於心，這樣才能往上扔更多的扭紋柴。這團亂麻越來越大，再也無法理清，最後束手無策。
隨着混亂的增加，團隊生產力也持續下降，趨向於零。當生產力下降時，管理層就只有一件事可做了：增加更多人手到項目中，期望提升生產力。可是新人並不熟悉系統的設計。他們搞不清楚什麼樣的修改符合設計意圖，什麼樣的修改違背設計意圖。而且，他們以及團隊中的其他人都揹負着提升生產力的可怕壓力。於是，他們製造更多的混亂，驅動生產力向零那端不斷下降。
[color=red][b]程序員起義[/b][/color]
最後，開發團隊造反了，他們告訴管理層，再也無法在這令人生厭的代碼基礎上做開發。他們要求做全新的設計。管理層不願意投入資源完全重啓爐竈，但他們也不能否認生產力低得可怕。他們只好同意開發者的要求，授權去做一套看上去很美的華麗新設計。
於是就組建了一支新軍。誰都想加入這個團隊，因爲它是張白紙。他們可以重新來過，搞出點真正漂亮的東西來。但只有最優秀、最聰明的傢伙被選中。其餘人等則繼續維護現有系統。
現在有兩支隊伍在競賽了。新團隊必須搭建一套新系統，要能實現舊系統的所有功能。另外，還得跟上對舊系統的持續改動。在新系統功能足以抗衡舊系統之前，管理層不會替換掉舊系統。
競賽可能會持續極長時間。我就見過延續了十年之久的。到了完成的時候，新團隊的老成員早已不知去向，而現有成員則要求重新設計一套新系統，因爲這套系統太爛了。
假使你經歷過哪怕是一小段我談到的這種事，那麼你一定知道，花時間保持代碼整潔不但有關效率，還有關生存。
