原則14：把相關(guān)的定義放在一起。設(shè)計代碼結(jié)構(gòu)時，確保高度相關(guān)的部分放在一起，有可能放在同一個類中。這是面向?qū)ο笤O(shè)計方法在封裝方面的一條標準原則。理想情況下，某個類之外的所有代碼不需要知道內(nèi)部運行的細節(jié)。有些開發(fā)人員喜歡將細節(jié)分散在多個文件中，以便按不同方式加以組織：比如為了把所有相同的數(shù)據(jù)類型放在一起，或者按字母順序進行組織。比方說，把一個類中所有常量放在與使用它們的包不同的另一個包當中，就會增加不必要的程序復(fù)雜性。指導(dǎo)原則應(yīng)該是按相關(guān)性進行分組，那樣可以隱藏復(fù)雜性。

    原則15：始終在簽入代碼之前運行測試。這條準則會幫助你滿足“千萬不要破壞編譯版本”的準則。

    原則16：倉促優(yōu)化是萬惡之源。程序教父don knuth的這句名言今天依然適用。應(yīng)當精心編寫代碼，避免微觀層面出現(xiàn)不必要的浪費，但應(yīng)該等到基于實際的最終用戶用例對整個程序進行壓力測試，再進行單個方法層面之外的優(yōu)化。要是僅僅基于對代碼的靜態(tài)了解，就憑直覺判斷什么對整體性能來說很重要，幾乎肯定出錯。相反，要度量整個系統(tǒng)的行為，找出真正影響性能的那1%的代碼，并關(guān)注這部分代碼。

    原則17：盡量減少積壓下來的沒有完成的編碼任務(wù)。開發(fā)人員開始編寫某個用例時，所有已被修改、但沒有完成及測試的代碼會發(fā)生成本。沒有完成的變更積壓幾天或幾周，會大大增加因改寫而導(dǎo)致浪費的風險。設(shè)想一下有三個任務(wù)，每個任務(wù)估計需要一天。同時開始這三個任務(wù)，同時工作三天就需要累計9個“單位”的成本。但如果按順序處理每個任務(wù)，一個任務(wù)完成后開始下一個，那么只需要3個“單位”的成本。這并不直觀。直覺告訴我們：我們在處理任務(wù)時，最好還是同時做三件事。但軟件不像實體構(gòu)造。短小、快速、完整的任務(wù)不但可以減輕認知負荷，還能減小未完成工作與另一個人的未完成工作發(fā)生沖突的可能性。

    原則18：千萬不要過于強調(diào)代碼的通用性。這就是有名的yagni，即“你不會需要它”。程序員在編寫某個特定類時，喜歡認為：只要稍加改動，該類可用于另外幾個用途。如果當前用例需要這些用途，那很好；但是程序員通常會考慮還沒有發(fā)明出來的用途，或者是實際上根本不需要的用途。（這個話題老是讓我想到宣傳某款產(chǎn)品既是地板蠟、又是甜食配料的搞笑電視節(jié)目。）

    原則19：能用兩行代碼，就堅決不要用三行。每當別人要讀代碼時，簡單的代碼總是一目了然。但也不要把代碼簡化到人家很難讀懂的地步。與冗長代碼相比，簡潔代碼更容易維護，也更容易發(fā)現(xiàn)其中的錯誤。始終要盡量簡化，但避免簡化過頭。

    原則20：千萬不要用行數(shù)來度量代碼。就完成特定任務(wù)所需的代碼行數(shù)而言，不同的程序員和編程風格會造成很大的差異。代碼行數(shù)說明不了代碼有多全面、質(zhì)量有多好。代碼質(zhì)量有可能千差萬別；與代碼質(zhì)量相比，代碼行數(shù)顯得沒有太大的意義。而是應(yīng)統(tǒng)計切實可行的用例有多少。

    原則21：持續(xù)不斷地重新設(shè)計和重構(gòu)。運用這條原則要慎重，因為有些代碼很脆弱、很難改變，但一般而言，你用不著害怕更改代碼以符合實際用例。某個數(shù)據(jù)成員過去可能是整數(shù)，但是當用例要求它是浮點數(shù)時，不要害怕更改。

    原則22：刪除無用代碼。說到并不完全了解的大段代碼，人們往往采取“別惹事生非”的做法。一個例子就是，為某個類增加一種新方法以替換另一種舊方法，而開發(fā)人員往往讓舊方法留在那里，僅僅為了“以防萬一”。應(yīng)當花一番工夫，看看需不需要該方法；如果沒有證據(jù)表明需要它，就刪除。最糟糕的做法莫過于注釋掉了大段代碼，卻任由這些注釋代碼留在原處。一旦你知道測試完畢，就應(yīng)當刪除注釋代碼，當然要在簽入之前。隨時添加代碼很容易，隨時刪除代碼卻很難。因此，如果你清楚不需要某部分代碼，那么只需下一點力氣，核實并消除此代碼就能讓代碼庫維護起來更容易。

    原則23：不要發(fā)明新語言。程序員喜歡讓驅(qū)動功能的文本文件在運行時可以靈活配置。有好多配置文件在不重新編譯的情況下能夠改變程序的行為。xml的出現(xiàn)讓一批專門定制的“腳本語言”層出不窮：有了這些語言，最終用戶不必編譯，就能夠“編程”以實現(xiàn)功能。這種推論的缺陷在于，要是離開了具體實現(xiàn)的環(huán)境，就幾乎根本無法明確規(guī)定操作行為的精確定義；而這些類型的腳本語言主要只適用于那些對相應(yīng)代碼的內(nèi)部運行有深入了解的人。因此，并不詳細了解內(nèi)部運行的實際最終用戶永遠不可能知道如何才能預(yù)料到復(fù)雜的命令組合會帶來什么影響。腳本語言是有用，也不能被抹殺，但是設(shè)計者必須采取一種極其保守的態(tài)度，盡可能使用現(xiàn)有語言，避免發(fā)明新的語言。

    原則24：等準備好了實現(xiàn)并測試實現(xiàn)代碼，再進行設(shè)計。你應(yīng)該總體上對工作方向有一些了解，并大致了解爭取建立的系統(tǒng)架構(gòu)。但在進入到可以實現(xiàn)及測試該設(shè)計的開發(fā)迭代階段之前，不要做詳細設(shè)計，也不要編寫功能實現(xiàn)的詳細描述。詳細設(shè)計應(yīng)當只涉及處理當前用例所需的那部分。軟件開發(fā)中造成浪費的最主要根源在于，把時間花在設(shè)計不需要、或者因為設(shè)計方面某些錯誤的假定而需要重新設(shè)計的部分上。

    原則25：設(shè)計是可塑的。不像實體構(gòu)造，軟件可以輕而易舉地進行重大改變。事實上，有許多證據(jù)可以證明：軟件比描述軟件的設(shè)計規(guī)格更容易改變。此外，軟件比規(guī)格更有效地傳達了設(shè)計思想。因此，你應(yīng)當把時間花在直接實現(xiàn)設(shè)計上，以便客戶能看到設(shè)計的具體細節(jié)。如果你缺少某些功能、因而要改變設(shè)計，改變軟件會比改變規(guī)格來得容易。但最重要的是，客戶看到代碼運行后，你就能非常清楚地知道客戶想要什么。

    原則26：花些時間編寫代碼來完整描述發(fā)現(xiàn)和報告異常情況的代碼中的問題。程序員往往很懶惰，對拋出的異常情況只給出簡單膚淺的描述，說明哪里出了錯。以為只有他們自己才會看到這個問題；只要借助含糊籠統(tǒng)的描述，就會記得該問題的意思。但實際上，因錯誤報告不準確或不完整而浪費在客戶支持情景上的時間比其他任何原因都要多。要編寫每一個錯誤消息，就好像你向剛走入房間、對代碼毫無經(jīng)驗的某個人說明情況。畢竟，客戶以及客戶支持團隊對代碼是毫無經(jīng)驗的。