先說說我們不喜歡的代碼長什么樣子，

1. 大函數，超過500行，甚至超過1000行;
2. 大量的hard coding;
3. if和else if中有明顯的條件關聯性;
4. 注釋和代碼邏輯不符合，函數名與功能不符合;
5. 命名英文拼音混雜，不少英文拼寫錯誤;
6. 。。。

說實話，這些問題很常見，無論是大廠，還是小團隊。問題出現了，想出怎么解決才是關鍵。

每個團隊都可以制定一套適合代碼規范，不過光有代碼規范是不夠的。

比如說寫代碼文檔，最重要的一點，不是什么格式規范，而是要說人話，解釋清楚你做的事情，不要解釋代碼，否則文檔本身就不具有可讀性。

不要為了寫注釋而寫，與其三心二意的寫一堆注釋，不如寫幾行足夠清晰的程序。

接下來，我列幾條我個人的經驗：

1. 不要重復發明輪子，將公共的方法和函數抽出來做成公共庫。投入一定的時間尋找和比較開源的解決方案，而非什么事情都自己實現。
2. 投入跟多的時間在接口的定義和審核上，一個差接口的危害性超過 500 行爛代碼。
3. 請部門里更有經驗的工程師幫助新人修改代碼，相互工程師之間，相互抽查代碼，這件事的好處不言而喻。雖然投入更多的時間，但是從整體效率的角度來講，提高代碼的可維護性就節省了大量的修改，重構代碼的時間，可謂磨刀不誤砍柴工。
4. 要求工程師對自己的代碼寫單元測試。這就使得程序員有機會從使用者的角度審視和檢測自己的代碼，這樣不但能提高代碼的易用性和正確性，而且在代碼發生改變的時候，程序員可以確保不會破壞引用此段代碼的其他模塊或項目。
5. 從個人角度看，提高代碼維護性，最直接的方式就是從好的代碼Github上的代碼庫中學習，多看多總結。
6. ***一點，也是我一直要求團隊的一點，團隊中的每個人都要有大局觀意識，埋頭苦干的前提是要了解全局，每位工程師都應該知道自己的東西在整個項目構架中的位置和他工作的意義。