前言
人跟人的能力千差萬別，所以寫出來的代碼質量，肯定是不同的。有的人，寫一個小邏輯，可能需要100行，而有的人，可能僅僅需要10行。代碼永遠會有Bug，在這方面沒有最好只有更好。模塊化與面向對象是實現高效無錯代碼的方法。高效無錯代碼需要思想與實踐的不斷反覆。如何做到代碼高效無錯，提高代碼質量的方法有哪些？又有哪些經驗和技巧呢？
一、代碼質量
軟件是交付給用戶，並由用戶體驗的產品；代碼則是對軟件正確且詳細的描述，所以代碼質量關係到軟件產品的質量。雖然軟件質量不等於代碼質量，但是代碼上的缺陷會嚴重的影響到軟件產品的質量。因此，爲提高代碼質量的投入是值得的。
二、衡量軟件產品質量的六個方面
- 功能性，即軟件是否滿足了客戶業務要求；
- 可用性，即衡量用戶使用軟件需要付出多大的努力；
- 可靠性，即軟件是否能夠一直處在一個穩定的狀態上滿足可用性；
- 高效性，即衡量軟件正常運行需要耗費多少物理資源；
- 可維護性，即衡量對已經完成的軟件進行調整需要多大的努力；
- 可移植性，即衡量軟件是否能夠方便地部署到不同的運行環境中；
三、提高代碼質量的具體經驗
1、永遠不要複製代碼
不惜任何代價避免重複的代碼。如果一個常用的代碼片段出現在了程序中的幾個不同地方，重構它，把它放到一個自己的函數裏。重複的代碼會導致你的同事 在讀你的代碼時產生困惑。而重複的代碼如果在一個地方修改，在另外一個地方忘記修改，就會產生到處是bug，它還會使你的代碼體積變得臃腫。
2、 測試你完成的代碼
你知道你的代碼能做什麼，而且試了一下，它確實好用，但你實際上需要充分的驗證它。分析所有可能的邊界情況，測試在所有可能的條件下它都能如期的工作。如果有參數，傳遞一些預期範圍外的值。傳遞一個null值。如果可能，讓同事看看你的代碼，問他們能否弄壞它。單元測試是到達這種目的的常規方法。
3、代碼審查
提交你的代碼之前，找個同事一起坐下來，向他解釋你做了哪些修改。通常，這樣做的過程中你就能發現代碼中的錯誤，而不需要同事說一句話。這比自己審查自己的代碼要有效的多得多。
4、 編寫不言自明的代碼
勿庸置疑，註釋是編程中很重要的一部分，但能夠不言自明的代碼跟勝一籌，因爲它能讓你在看代碼時就能理解它。函數名變量名要慎重選擇，好的變量/方法名字放到語言語義環境中時，不懂編程的人都能看懂。
5. 不要使用純數字
直接把數字嵌入代碼中是一種惡習，因爲無法說明它們是代表什麼的。當有重複時更糟糕——相同的數字在代碼的多個地方出現。如果只修改了一個，而忘記了其它的。這就導致bug。一定要用一個命名常量來代表你要表達的數字，即使它在代碼裏只出現一次。
6. 不要做手工勞動
當做一系列動作時，人類總是喜歡犯錯誤。如果你在做部署工作，並且不是一步能完成的，那你就是在做錯事。儘量的讓工作能自動化的完成，減少人爲錯誤。當做工作量很大的任務時，這尤其重要。
7、不要試圖死磕代碼加快速度，找個更加有效的算法可能更加有效。
8、代碼要先做對，在弄快。先使其可靠，再讓其更快。先把代碼弄乾淨，再讓它變快
9、當發現一個函數具有以下特徵時，需要考慮抽取函數
- (1)、過長
- (2)、嵌套層數過深。
- (3)、自然分塊，需要使用註釋描述該程序塊
- (4)、判斷條件過於複雜
- (5)、函數的某些判斷分支不斷變化
- (6)、參數過於複雜
- (7)、邏輯重複
10、局部變量應當用途單一
11、將整潔的代碼風格作爲一種習慣，時刻意識到整潔代碼的重要性並不斷地提高重構技巧
12、關於註釋
- (1)、如果能用短小函數描述，則使用子函數替代註釋本身。
- (2)、確保註釋和代碼表達的意圖一致，否則就失去了註釋的意義。
- (3)、在重要的地方寫註釋，不要註釋滿天飛，簡單的重複代碼的功能是毫無意義的。要讓每一處註釋都有價值。不要過分註釋。
13、關於何時重寫代碼
開發團隊要預留20% 的時間用作保持對原有系統的重構。剩餘的時間用作開發新功能。只要有可能，所要重構的部分進行遞增修改，讓用戶切身感受到產品的改進，哪怕將工作時間延長。