我們都知道，一個軟體的維護成本往往要高於其研發成本。在維護過程中，我們的程式碼需要不斷的進行迭代。迭代的目的有兩個：修復bug和增加新特性。但是迭代也會帶來一系列新的問題，比如新的bug，或者是破壞程式碼的整潔性。這裡我們從保持程式碼整潔性的角度來討論一下迭代的幾個原則。
執行所有測試
沒錯，首先的要說的還是測試，我們要在每次迭代程式碼之後，執行所有的測試，如有必要，也要編寫新的測試。我們要編寫儘量簡單的測試，簡單的測試會驅使我們降低類與類之間的耦合度。如果還不瞭解如何編寫單元測試，可以參考一下舊文程式碼潔癖系列（七）：單元測試的地位。良好的測試不但是程式碼質量的保證，同時也是良好設計的引導。
不要重複“造輪子”
記得我的leader曾經告訴過我：寫每一行程式碼之前，要先思考一下有沒有必要寫這行程式碼。在實現一個功能之前，先確認一下這個功能是否已經被實現了。永遠不要重複“造輪子”。但是，當我們進行一定的共性抽取時，可能已經違反了SRP原則（Single Responsibility Principle）。因此，抽取出的方法可能需要放在其他類中。
可讀
程式碼是程式設計師之間的交流工具，要想獲得其他程式設計師的尊重，必須使你的程式碼具備可讀性。這也是我們要保持程式碼整潔的原因。如何保證程式碼的可讀性呢？首先需要的就是有意義的命名，關於命名規則，可以參考程式碼潔癖系列（二）：命名的藝術這篇文章，其次就是通過測試用例讓別人瞭解你的程式碼。
儘可能少的類和方法
在程式碼潔癖系列（三）：整潔的類和函式一文中，我們說過類和函式都應該儘量短小。有人問了，為了類和函式都足夠短小，我要把程式碼拆分成許多的類嗎？這裡需要說明一下，在這方面，我們並不需要追求極致。應該根據實際情況，合理的拆分。所以，也要儘量減少類和方法，這可能與“類和函式應該短小”這一原則相矛盾。這需要工程師自己去衡量了，首先要保證“類和函式應該短小”，其次才是儘可能減少類和方法。
結束語
到這裡，”程式碼潔癖系列“的文章要告一段落了，希望大家在寫程式碼的時候可以多思考，保證自己程式碼的整潔性。文章有什麼問題，或者我有哪些遺漏的地方，大家可以通過去我的微信公眾號後臺留言和我討論。