下面，我將作為一名有著多年編程經(jīng)驗的專業(yè)程序員，分享一些精華——它們已經(jīng)幫助我提高了我的代碼質(zhì)量和整體的工作效率，希望也能對你有所裨益 。
不惜一切代價也要避免重復(fù)代碼。如果你有幾個不同的地方經(jīng)常性地要使用某個代碼片段，那么可以將它重構(gòu)成函數(shù)。代碼重復(fù)不但會導(dǎo)致閱讀混亂，導(dǎo)致bug——修復(fù)了這里的重復(fù)片段，卻遺漏了其他地方的，還會導(dǎo)致代碼庫的臃腫和可執(zhí)行文件大小的膨脹?，F(xiàn)在的編程語言，能大大改善這方面的麻煩。
當(dāng)你發(fā)現(xiàn)自己在刷Facebook和Twitter——不能專注于解決問題了，那么這往往意味著你需要稍作休息了。不妨離開辦公桌去喝杯咖啡，和同事聊上個5分鐘。不要以為這是在浪費(fèi)時間，從長遠(yuǎn)來看這能讓你更富有成效。
在高壓下想出的解決方案，修復(fù)的bug，很容易因為過于興沖沖，而將平時銘記于心的關(guān)鍵測試周期完全拋之于腦后。但是這往往會導(dǎo)致更多的問題，并且會讓你在老板和同事眼中看起來顯得不那么專業(yè)。
你知道你的代碼應(yīng)該做什么，并且可能已經(jīng)測試過了，但是，你需要證明這一點(diǎn)。分析所有可能的邊緣情況，并給出測試，以便確定你的代碼在所有可能的條件下都可以正常執(zhí)行。如果有參數(shù)，那么發(fā)送一些預(yù)期的范圍之外的值。還可以發(fā)送null值。如果可以的話，不妨讓你的同事來搞搞破壞——單元測試是一條正規(guī)的康莊大道。
在你將代碼提交到源代碼控制之前，最好先將你所做的改動給你的同事解釋一下。有時候往往只需要這樣做，就能讓你意識到自己代碼的錯誤，即使你的同事不發(fā)一言。這可比僅僅只是自己回顧自己的工作要來得高效得多了。
如果你用了大量代碼來執(zhí)行一些簡單操作，那么很有可能是你走錯路了。代碼越是精簡越好——調(diào)試少了，重構(gòu)少了，問題自然也少了。但是要注意的是：可讀性同樣重要。誰也不希望在精簡代碼的同時影響了代碼的可讀性。
所謂優(yōu)雅的代碼，不但具備極強(qiáng)的可讀性，還能以最少量的代碼和機(jī)器操作來解決手頭的問題。要想在所有情況下都能夠做到代碼的優(yōu)雅，其實(shí)是相當(dāng)難的，但是經(jīng)過一段時間的編程之后，你會逐漸體悟到“優(yōu)雅代碼”應(yīng)該是怎么樣的。優(yōu)雅的代碼無法通過重構(gòu)來做任何改進(jìn)——為此自豪吧。
注釋是編程的一個非常重要的組成部分，但是自文檔化的代碼之所以能更勝一籌，是因為只通過閱讀代碼就能讓人理解。通過巧妙選擇函數(shù)名和變量名，再聯(lián)系語言語義，就能夠使得代碼變得可讀，哪怕閱讀者是非編程人員。
不過，自文檔化的代碼并不能替代注釋。使用注釋來解釋“為什么”，用自文檔化的代碼來描述是“什么”。
光是將數(shù)字插入到代碼中是不對的，因為沒人能理解它們代表了什么。這會混淆我們——當(dāng)相同的數(shù)字用于代碼中多個不同地方的時候。有的地方可能會因此而導(dǎo)致變化，也有的會因此而產(chǎn)生bug。盡量使用命名的常量來描述要表達(dá)的值，即便它僅用于一個地方。
當(dāng)我們在做一連串的動作時，是很容易犯錯的。如果你的部署進(jìn)程不只一個步驟，那么你出錯了。我們應(yīng)該盡可能地自動化，以減少人為犯錯的機(jī)會。如果你需要執(zhí)行很多任務(wù)的話，自動化就顯得尤為重要了。
一旦你開始優(yōu)化已經(jīng)可以成功運(yùn)行的代碼，那么就會有破壞功能的風(fēng)險。優(yōu)化應(yīng)該只響應(yīng)于性能分析，在項目結(jié)束的時候進(jìn)行。提前于分析階段的優(yōu)化不但浪費(fèi)時間，還會導(dǎo)致bug。
來源：CSDN博客，作者：Satisfied_zx，更多精彩博文請猛戳左下角“閱讀原文”查看吧！
聯(lián)系客服
