一、糟糕的程式碼

        作者用一個故事講述了糟糕的程式碼造成的後果：

        有家公司寫了個很流行的應用，推出後很多專業人士都買來用。但是好景不長，慢慢的釋出週期開始拉長，bug總是不能修復，裝載的時間越來越久，崩潰的機率越來越大。以至於所有的使用者都拋棄了這款應用，然後這家公司倒閉了。後來，作者遇到該公司的僱員時向他了解當年的情況，那位僱員說，當時他們趕著推出產品，程式碼寫的亂七八糟，特性越加越多，程式碼也越來越爛，最後再沒有辦法管理這些程式碼了。最終糟糕的程式碼致使這家公司倒閉，由此可見糟糕的程式碼帶來的危害。

        那麼你曾為糟糕的程式碼困擾過嗎？答案我想是肯定的。那麼為什麼還要寫糟糕的程式碼呢？

        是想快點完成嗎？是要趕專案週期嗎？有可能，或許你覺得自己要幹好所需時間不夠，或許你如果花時間清理程式碼，從而拖延了專案週期就會導致經理或者老闆大發雷霆；或許你只是不耐煩再搞這套程式，期望儘早結束這個專案；或許你手上還積壓著別的工作，讓你意識到趕緊弄完手上的東西，然後進行下一項工作。凡此種種，我想大家都經歷過。我們都曾瞟了一眼自己親手造成的混亂，然後決定棄之不顧，走向新一天。我們都曾看到自己寫的爛程式居然能執行，然後斷言能執行的爛程式總比什麼都沒有要強。我們都說過先放一放再回頭處理，當然，在那日子裡我們都沒聽過勒布朗法則：稍後等於永不。

二、混亂的代價

        有過幾年程式設計經驗的人都應該被糟糕的程式碼困擾過，遇到這種程式碼的時候有可能就會嚴重拖延專案進度。因為你每次修改的時候都會影響到其他幾處程式碼。程式碼無小事，每次新增或者修改程式碼，你都得對之前的程式碼瞭然於心，然後才能新增或者修改，然後這團亂麻就會越來越大，直到再也無法清理，無法維護，束手無策。隨著混亂的增加，團隊的生產效率也逐漸下降，甚至趨向於零。當生產力下降，管理層能做的只是增加人手進入到這個專案中，期望能夠提升生產效率，但是新人對系統業務不熟悉，不知道怎麼改才符合設計，怎麼改算違背設計。然後還揹負著提升效率的責任，最後只能越來越混亂。最後的最後，開發團隊要求管理層重新寫一個新系統，做全新的設計，不但要實現老系統的所有功能，並且能夠持續改動。然後在新系統出來之前繼續維護老系統，知道新系統能夠與老系統抗衡或者超越，才會把老系統替換為新系統。

三、專業的做法

        當產品經理要求你做一個功能時，一定要站在開發的角度好好考慮一下可能性，如果你認為不能實現或者有更好的方式就可以明確的拒絕他，並告訴你的理由。這樣是對你的專案負責，對你負責，是專業的做法。

四、謎題

        程式設計師面臨一道基礎價值謎題。有幾年開發經驗的人都知道，之前的混亂拖了自己的後腿，但開發者揹負期限的壓力，只好基於糟糕的程式碼繼續製造混亂。 但是你要明白製造混亂無助於趕上期限，混亂只會立刻拖慢你，叫你錯誤期限，趕上期限的唯一辦法就是始終保持程式碼的整潔。

五、什麼是整潔程式碼

• 程式碼邏輯直截了當，叫缺陷無處隱藏
• 儘量減少依賴關係，使之便於維護
• 將效能調製最優，省的引誘別人做不合理的優化而搞出一堆混亂
• 幾乎沒有改進的餘地，程式碼作者什麼都想到了，如果你企圖改進它，總是會回到原點
• 能通過所有的測試
• 沒有重複的程式碼
• 體現系統中全部的設計理念
• 運用盡量少的實體，比如類、方法、函式等

六、童子軍軍規

        美國童子軍的一條簡單軍規，應用到我們的專業領域： 讓營地比你來時更乾淨。

        對於我們來說就是，每次修改或者新增程式碼後要比你修改或新增前要乾淨整潔；程式碼遷入之後要比遷入之前乾淨(也許只是改好一個變數名，拆分一個過長的函式，消除一些重複的程式碼)。