完美主義對程序員的影響

代碼重要性區分

一個系統能夠維持 5 年，10 年，甚至 20 年以上，可是代碼和設計模式的生命週期很是短，當對一個解決方案使用不一樣的方法進行迭代的時候，一般只能維持數月，很多天，甚至幾分鐘的時間。

隨着對代碼是如何改變的研究，致力於代碼修改藝術的人發現了一個代碼庫的規律曲線。每一個系統都有不少從未改變的代碼。可是也有小部分很是重要且有用的代碼一次又一次的改變，通過了屢次重構和重寫。

當你對一個系統，問題域，或者架構方法愈來愈熟悉的時候，就更容易發現和預測哪些代碼會常常修改，哪些代碼不會被修改，即區分重要代碼和非重要代碼。

咱們應該嘗試追求完美代碼？

衆所周知，咱們應該寫乾淨整潔的代碼，而乾淨整潔就應該是儘量一致，易懂，簡單。

有些人追求極致，強迫本身寫的代碼要漂亮且優雅，接近於他們所能達到的完美，瘋狂的進行重構，並致力於每個細節。

與寫完代碼再也不變更相比，一直修改的代碼會讓完美的需求和具備前瞻性的設計變得有些多餘和不必。

你不能寫出完美的軟件，這樣的結果會使你受傷了？不必，把它當作人生格言，信奉並祝賀，由於完美的軟件並不存在，在計算機歷史中沒一我的曾經寫出過完美軟件，固然，你也不可能成爲第一個，只有接受這樣一個事實，你才能再也不在浪費時間，將精力放在可能實現的理想中。

Andrew Hunt

曾經寫過的代碼不須要優美優雅。它必須是正確的且容易理解的，由於在系統的生命週期中那些從不用修改的代碼也會被屢次訪問。一樣這些代碼不須要又整潔又緊湊——只要整潔就足夠了。在必定程度上，複製粘貼和其餘快捷方法寫出的代碼是容許的。即便這些代碼周圍的代碼變了，這些代碼不須要反覆修改，不須要重構（直到你須要修改它）。這樣的代碼是不值得花費額外的時間的。

那些常常修改的代碼該如何處理呢？苦思冥想代碼風格和提出最優雅的解決方案是浪費時間的，由於這些代碼可能會在幾天或幾周以內再次修改，甚至重寫。由於但願代碼應該變得更好而癡迷地重構那些須要常常修改代碼，或者重構那些基本不會修改的代碼。代碼一直能夠變得更好，但這並不重要。

最重要的是：代碼是否作到了它應該作的事？代碼運行正確且可用又高效嗎？可以處理錯誤和錯誤數據而不奔潰或者至少是安全地出錯嗎？容易調試嗎？能簡單又安全地修改代碼嗎？這些不是對於完美代碼的主觀想法，而是用來區分紅功和失敗的切實可行的措施。

實用的編碼和重構

精益開發的核心思想是：不要浪費時間在那些不重要的事情上。這句話已告訴咱們該怎樣寫代碼，怎樣重構代碼，怎樣評審代碼，怎樣測試代碼。

爲了把工做作好，只重構你須要的——Martin Fowler 稱爲機會主義重構（理解、清理不切實際的東西）和預先重構。足夠讓修改變得更簡單更安全便可，其餘的沒必要考慮。若是你不修改那些代碼，那麼那些代碼長什麼樣子是無所謂的事。

在代碼評審中，只關注那些重要的。代碼正確嗎？有防範機制嗎？安全嗎？容易理解嗎？可以安全地修改嗎？

忘掉編碼風格（除非編碼風格達到可理解的程度）。讓你的 IDE 處理格式化。不要過多爭論：代碼是否能夠是「更多的 OO」。只要它有意義，無論它是否適當地遵循這種或那種模式，這些都不重要。不管你喜歡仍是不喜歡都不要緊。不管你可否以更好的方式作到這一點並不重要——除非你在教一個對平臺和語言都不熟悉的新手，並且你須要作一些代碼評審做爲指導的一部分。

寫測試是有必要的。測試那些涵蓋主路徑和重要例外狀況的測試。測試可讓你以最少的工做量得到最多的自信心。大規模全範圍測試或者小規模局部測試——在編寫代碼以前測試仍是以後測試，都不要緊，只要作了這個工做就行。

這不（僅）是關於代碼

建築學和工程學的隱喻從未在軟件開發中生效。咱們不是設計和建造橋樑或摩天大樓 —— 它們會在幾年或幾代內保持基本相同。咱們正在建造一些更富有創造力和抽象性、更加短暫的東西。代碼編寫以後是用來修改的 —— 這就是爲何它被稱爲「軟件」的緣由。

「通過五年的使用和修改，成功的軟件的源碼一般與最第一版本徹底不同，而五年以後的成功的建築幾乎沒有什麼變化。」

Kevin Tate

咱們須要將代碼看做是咱們工做的一個暫存：

…有時在面對更重要的事情時，咱們被引導到盲目崇拜代碼。咱們常常會處於這樣的幻象中：在移交產品時最有價值的東西是代碼，實際上這多是對問題域的理解、設計難題的進展甚至是客戶反饋。

Dan Grover

迭代開發教會了咱們經過實驗來驗證咱們工做的結果 —— 咱們是否已解決了這個問題，若是沒有，咱們學到了什麼，咱們該如何改進？咱們正在構建的軟件永遠不會完成。即便設計和代碼是正確的，它們可能也只是在一段時間內是正確的，直到環境要求其再次改動或被替換爲更好的東西。

咱們須要編寫好的代碼：可理解、正確、安全和可靠的代碼。咱們須要重構和審查它，並寫出好的有用的測試用例，直到其中的一些代碼（也多是所有），可能會很快被拋棄，或者可能永遠不會被再次看到，或根本不會使用了。咱們須要認識到，咱們的一些工做必然會被浪費掉，並要爲此進行優化。作那些必須作的，不作無用功。不要浪費時間嘗試編寫完美的代碼。