咱們都知道，一個軟件的維護成本每每要高於其研發成本。在維護過程當中，咱們的代碼須要不斷的進行迭代。迭代的目的有兩個：修復bug和增長新特性。可是迭代也會帶來一系列新的問題，好比新的bug，或者是破壞代碼的整潔性。這裏咱們從保持代碼整潔性的角度來討論一下迭代的幾個原則。程序員
運行全部測試web
沒錯，首先的要說的仍是測試，咱們要在每次迭代代碼以後，運行全部的測試，若有必要，也要編寫新的測試。咱們要編寫儘可能簡單的測試，簡單的測試會驅使咱們下降類與類之間的耦合度。若是還不瞭解如何編寫單元測試，能夠參考一下舊文代碼潔癖系列（七）：單元測試的地位。良好的測試不可是代碼質量的保證，同時也是良好設計的引導。微信
不要重複「造輪子」編輯器
記得個人leader曾經告訴過我：寫每一行代碼以前，要先思考一下有沒有必要寫這行代碼。在實現一個功能以前，先確認一下這個功能是否已經被實現了。永遠不要重複「造輪子」。可是，當咱們進行必定的共性抽取時，可能已經違反了SRP原則（Single Responsibility Principle）。所以，抽取出的方法可能須要放在其餘類中。函數
可讀工具
代碼是程序員之間的交流工具，要想得到其餘程序員的尊重，必須使你的代碼具有可讀性。這也是咱們要保持代碼整潔的緣由。如何保證代碼的可讀性呢？首先須要的就是有意義的命名，關於命名規則，能夠參考代碼潔癖系列（二）：命名的藝術這篇文章，其次就是經過測試用例讓別人瞭解你的代碼。單元測試
儘量少的類和方法測試
在代碼潔癖系列（三）：整潔的類和函數一文中，咱們說過類和函數都應該儘可能短小。有人問了，爲了類和函數都足夠短小，我要把代碼拆分紅許多的類嗎？這裏須要說明一下，在這方面，咱們並不須要追求極致。應該根據實際狀況，合理的拆分。因此，也要儘可能減小類和方法，這可能與「類和函數應該短小」這一原則相矛盾。這須要工程師本身去衡量了，首先要保證「類和函數應該短小」，其次纔是儘量減小類和方法。flex
結束語spa
到這裏，」代碼潔癖系列「的文章要告一段落了，但願你們在寫代碼的時候能夠多思考，保證本身代碼的整潔性。文章有什麼問題，或者我有哪些遺漏的地方，你們能夠經過去個人微信公衆號後臺留言和我討論。
本文分享自微信公衆號 - 代碼潔癖患者（Jackeyzhe2018）。
若有侵權，請聯繫 support@oschina.cn 刪除。
本文參與「OSC源創計劃」，歡迎正在閱讀的你也加入，一塊兒分享。