一般而言，一個系統(tǒng)能用 5 年、10 年，甚至 20 年以上。但是某特定代碼行以及某特定設(shè)計則往往比較短：當我們使用了不同的解決方法，其生命周期可能就只有幾個月、幾天，甚至是幾秒種的時間。
有的代碼就是比其他代碼更重要
通過研究代碼如何隨時間變化，Michael Feathers 確定了代碼庫的功率曲線。每個系統(tǒng)都有代碼，通常而言里面的很多很多代碼，一次寫好之后就永遠不會變了的。但是還是有少量的代碼，包括最重要和最有用的代碼，會被一遍又一遍地改動、重構(gòu)甚至是重頭開始重寫。
隨著你對系統(tǒng)、問題領(lǐng)域以及架構(gòu)方法方面經(jīng)驗的增長，就更加容易知道和預(yù)測什么代碼總是需要改動的，什么代碼是永遠不會變的：有的代碼就是比其他代碼更重要。
我們是否應(yīng)該寫完美代碼？
我們知道，我們應(yīng)該寫干凈的代碼，一致的、易于理解的且越簡單越好的代碼。
有些人因此而走向了一個極端，強迫自己盡可能地編寫美麗優(yōu)雅趨于完美的代碼，著魔于重構(gòu)，可著勁兒折騰每一個細節(jié)。
有的代碼只需要寫一次，以后就再也不需要作任何變動。但有些代碼則并非如此，試想，這些需要不斷改變的代碼，代碼寫得那么完美卻在下一秒就立馬被 delete 不就太過浪費了嗎？而且也沒有必要這么做。
“你不用去寫所謂完美的軟件。不是禁止你，只是真的沒有這個必要。好好想想，接受這個話。你需要明白完美的軟件其實是不存在的。計算機發(fā)展到今天還沒有人寫的軟件是完美的。你也不要自以為是地想去做第一個。除非你能接受這個事實，否則你最終只會是在浪費時間和精力，如果你想追求這個不可能實現(xiàn)的夢想。”
——Andrew Hunt，《The Pragmatic Programmer: from Journeyman to Master》的作者
一次就能解決的代碼也不需要美麗和優(yōu)雅，只要保證是正確的、容易理解的即可——因為這些不變的代碼可能以后還要被多次讀取。也不必非要是干凈和緊密的——只需要干凈即可。復(fù)制和粘貼等快捷方式在這類代碼上是被允許的，至少在一定程度上可以這么做。這些代碼不需要再重構(gòu)（除非你需要改變這些代碼），即使它周圍的其他的代碼一直在變化中。總之一句話，這些代碼不值得我們在它身上花費額外的時間。
至于那些一直在變化的代碼？苦苦思索最優(yōu)雅的解決方案純粹是在浪費時間，因為這段代碼很可能在幾天或者幾周后就會被改寫，甚至重寫。
所以我們要關(guān)注的重點是：這些代碼是否如愿運行——是否正確、實用和高效？是否能處理異常數(shù)據(jù)而不崩潰？——或者至少是否能做到即使失敗也不會出問題？是否容易調(diào)試？是否能簡單安全地改變？這些實實在在的措施才是成功與失敗之間的分水嶺。
編碼與重構(gòu)要務(wù)實
精益開發(fā)的核心思想是：不要浪費時間去做那些不重要的事情，包括寫代碼、重構(gòu)、代碼審查以及代碼測試等多個方面。
只需要重構(gòu)真正需要的部分就足夠了——這也被 Martin Flower 稱之為是機會主義的重構(gòu)和有準備的重構(gòu)。
關(guān)于代碼審查也只需要專注于重要部分。這些代碼是否正確？是否安全？是否可以運行？
不要在意風格（除非風格本身妨礙了我們的理解）。讓 IDE 做主，格式化的照顧就 ok 了。我們不必去討論代碼還能不能更 OO，也不必一定要遵循某種樣式，喜歡與否也沒有關(guān)系，是否能用更好的方式解決也不重要——除非是你在教新手，并且需要做一些指導(dǎo)作為代碼審查的一部分。
測試也要挑關(guān)鍵的來。測試要覆蓋主要途徑和重要的異常情況。無論是大型測試還是小而集中的測試，無論是寫在代碼之前還是之后，只要能起到作用就成。
這不僅僅是代碼問題
軟件開發(fā)總是在不斷地更新迭代。哪怕現(xiàn)在看它的設(shè)計和代碼是正確的，但是一段時間之后，它就會被要求改變或者直接被其他更好的所替代。
我們需要編寫優(yōu)良的代碼：易于理解、正確以及安全。我們在重構(gòu)和審查代碼、編寫有用的測試的同時也需要謹記：有些代碼或者甚至是所有的這些代碼，在不久的將來是要被拋棄的，或者永遠也不會再被讀取，或者再也不會被使用了。我們必須意識到，我們現(xiàn)在的一些工作將會成為無用功。做需要做的事情，僅此就夠了。不要浪費時間去寫所謂的完美代碼。
英文原文：Don't Waste Time Writing Perfect Code
京公網(wǎng)安備 11010502049343號