先說(shuō)說(shuō)我們不喜歡的代碼長(zhǎng)什么樣子，

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

說(shuō)實(shí)話，這些問(wèn)題很常見(jiàn)，無(wú)論是大廠，還是小團(tuán)隊(duì)。問(wèn)題出現(xiàn)了，想出怎么解決才是關(guān)鍵。

每個(gè)團(tuán)隊(duì)都可以制定一套適合代碼規(guī)范，不過(guò)光有代碼規(guī)范是不夠的。

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

不要為了寫(xiě)注釋而寫(xiě)，與其三心二意的寫(xiě)一堆注釋?zhuān)蝗鐚?xiě)幾行足夠清晰的程序。

接下來(lái)，我列幾條我個(gè)人的經(jīng)驗(yàn)：

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