好的程序需要你至少好好寫兩遍

　　最近這些年，越來越多的人開始轉向敏捷開發。各種敏捷開發技術并不新鮮，大多是在80 和 90年代發展形成。但只是在最近這些年，程序員和(更重要的是)一些商業顧問，架構師，客戶開始變得喜歡和擁抱敏捷開發。

　　進化中的需求

　　現在的一種普遍的認識是，在開始編碼前，你不可能把所有的需求都寫完備。這些需求的確定是一個逐漸發展進化的過程。使用短開發周期/springts，我們一步步的開發程序，使用多次迭代的方式完成從客戶方得到的最新需求。這些都是基于一個進化的思想。就像生活中，我們總是通過一步步的改進來達到最好一樣。

　　進化中的代碼!

　　可是，這就完事了嗎?如今大部分的程序員都認識到了需求必定是一步步的挖掘出來的。但他們卻忘了自己的工作!?他們仍然認為他們的框架和架構在項目開始之初就定型了。同樣，代碼一旦寫成，程序就完成了… 不是嗎?

　　錯。以我的經驗，所有好的程序都至少要寫兩遍。第一編是你過于倉促，不能很好的理解需求、實現需求。不錯，當看到了某種業務模式，我們知道要提煉出方法，圍繞著它實現業務職責。你最終寫成的代碼是非常好的，但，它不是優秀的。

　　在我們目前的項目中，幾乎所有的重要功能模塊都從頭重寫過數次。慢慢的但明顯的，代碼變得越來越好。一旦你對某段程序做了第三或第四次增補，或又找到了一個bug，你能感覺到這程序什么地方有異味。你開始躲避觸碰這段程序，你為不需要在處理這段程序而高興。當有了這樣的感覺后我會怎么做?我會刪了這些代碼。

　　可是… 可是… 這樣你就要完全從頭開始了!?

　　你又錯了! 當然，IDE里空了，代碼全沒了，也許一些測試程序會存留下來。但你卻對你的代碼應該做什么有了扎實的認識。你也知道以前這段代碼是什么樣的，你知道它以前的內傷和異味在哪里!有了這些認識，你能寫出更好，甚至是非常優秀的代碼!不錯，我們也可以保留這些代碼，使用一些重構措施…但你可能再也找不到這樣好的從頭開始、更好的編寫它的機會了。

　　再次，就像生活中的所有事情：要讓事情變的完美，你需要經過多次的進化迭代。對你的需求是這樣，對你的架構和代碼也是如此。

　　寫兩遍，就意味著兩倍的時間嗎?

　　當告訴人們我的觀點是所有的程序都至少寫兩遍時，他們擔心花費兩倍的項目時間。但事實遠非如此。下面是原因：

　　第二次寫代碼只是用去你初次寫代碼的很少一部分的時間。

　　重寫之后，代碼的質量會有明顯的提高，可維護性，可擴展性都有改善，包括編程的速度。

　　祝你好運，堅持重新改進你的代碼!

原文轉自：http://www.aqee.net/great-code-is-written-twice-or-more/