好的程式碼至少要修改兩遍

近些年來，越來越多的人開始轉向敏捷開發，而且這些敏捷開發的技術已不再新鮮，大多都是在 80 和 90 年代設計形成的。但是，最近幾年，程式設計師，特別是一些商業顧問，架構師和客戶開始喜歡上了敏捷開發。

不斷進化的需求

現如今，有一個普遍的認識就是在你開始專案程式設計之前，你不可能寫下所有的需求，這些需求的確定需要一個不斷進化的過程。在較短的開發週期中，我們不斷的完善程式，多次迭代從而滿足客戶提出的最新需求。這些都是基於進化的原則，就像我們的生活，你是一步一步的向前從而做得更好。

不斷進化的程式碼

這就可以了嗎？現在的大多數程式設計師都已經認識到了需求是不斷進化和完善的。但還不夠，他們依舊認為專案使用的框架和架構應該在專案開始的時候就確定了，而且程式碼一旦完成，就一切都 OK 了。

錯。根據我的經驗，所有優秀的程式碼都至少要寫兩遍。第一遍寫程式碼時，你通常會很匆忙，不能很好的理解並實現需求。當然，如果你看過一些設計模式，知道一些方法，你最終的程式碼可能會寫得不錯，但它絕不是最優秀的。少寫一些無謂的程式碼，多一些思考。

在我們現在的專案中，幾乎所有重要的功能都要從零開始寫，並且重複修改很多次。這雖然很慢，但確定的是寫出的程式碼越來越好了。當你修改某一部分的程式碼已經三到四次，或又修補了這裡的一個 bug，你就開始有點想躲避這部分程式碼，如果不再處理它你就會很高興。當有了這樣的想法後，你肯定會刪了這些程式碼。那就又要一切從頭開始了嗎？

再一次錯。確實，IDE 裡空了，程式碼沒了，或許只有一些測試程式還在。但是，你已經對你寫的這些程式碼有了深刻的認識，你知道它是什麼樣的，你也知道它的問題出在哪。在此基礎上，你現在可以寫出更好，甚至是優秀的程式碼。當然了，我們也可以保留之前的程式碼，進行一些重構等等，但都不如從頭開始，更好的做出它。

這和生活中的道理依然是一樣的，要想把一件事做到極致，就要多次的重複和進化。你的需求是這樣，你的程式碼和架構也要這樣。

寫兩遍程式碼會花費兩倍的時間？

當我告訴人們所有的程式都要至少寫兩遍時，他們擔心這樣會使完成整個專案的時間加倍。但事實不是這樣的，我來告訴你原因：

1. 第二次寫程式碼，只會花費你第一次寫程式碼時的部分時間；

2. 重寫之後的程式碼在質量上會有顯著提高，而且維護性和可擴充套件性都會更好，你的程式設計速度也會越來越快。

所以，堅持重寫你的程式碼，不斷優化它吧！