寫出高質量代碼的10個建議
很長一段時間以來，我都在關注如何提高代碼質量，也為此做過一些嘗試，我想這個話題可能大家會比較感興趣，在這里分享一下我關于如何提高代碼質量的一些體會。
1. 打好基礎
</h2>
<p>
寫出高質量代碼，并不是搭建空中樓閣，需要有一定的基礎，這里我重點強調與代碼質量密切相關的幾點：
</p>
<ul>
<li>
<strong>掌握好開發語言</strong> ，比如做Android就必須對Java足夠熟悉，《Effective Java》一書就是教授大家如何更好得掌握Java, 寫出高質量Java代碼。
</li>
<li>
<strong>熟悉開發平臺</strong> , 不同的開發平臺，有不同的API, 有不同的工作原理，同樣是Java代碼，在PC上寫與Android上寫很多地方不一樣，要去熟悉Android編程的一些特性，iOS編程的一些特性，了解清楚這些，才能寫出更加地道的代碼，充分發揮各自平臺的優勢。
</li>
<li>
<strong>基礎的數據結構與算法</strong> ，掌握好這些在解決一些特定問題時，可以以更加優雅有效的方式處理。
</li>
<li>
<strong>基礎的設計原則</strong> ，無需完全掌握23種經典設計模式，只需要了解一些常用的設計原則即可，甚至你也可以只了解什么是低耦合，并在你的代碼中堅持實踐，也能寫出很不錯的代碼。
</li>
</ul>
<h2>
2. 代碼標準
</h2>
<p>
代碼標準在團隊合作中尤為重要，誰也不希望一個項目中代碼風格各異，看得讓人糟心，即便是個人開發者，現在也需要跟各種開源項目打交道。標準怎么定是一個老生常談的話題，我個人職業生涯中經歷過很多次的代碼標準討論會議，C++, C#, Java等等，大家有時會堅持自己的習慣不肯退讓。可現如今時代不一樣了，Google等大廠已經為我們制定好了各種標準，不用爭了，就用這些業界標準吧。
</p>
<h2>
3. 想好再寫
</h2>
<p>
除非你很清楚你要怎么做，否則我不建議邊做邊想。 <br />
1. 打好基礎
</h2>
<p>
寫出高質量代碼，并不是搭建空中樓閣，需要有一定的基礎，這里我重點強調與代碼質量密切相關的幾點：
</p>
<ul>
<li>
<strong>掌握好開發語言</strong> ，比如做Android就必須對Java足夠熟悉，《Effective Java》一書就是教授大家如何更好得掌握Java, 寫出高質量Java代碼。
</li>
<li>
<strong>熟悉開發平臺</strong> , 不同的開發平臺，有不同的API, 有不同的工作原理，同樣是Java代碼，在PC上寫與Android上寫很多地方不一樣，要去熟悉Android編程的一些特性，iOS編程的一些特性，了解清楚這些，才能寫出更加地道的代碼，充分發揮各自平臺的優勢。
</li>
<li>
<strong>基礎的數據結構與算法</strong> ，掌握好這些在解決一些特定問題時，可以以更加優雅有效的方式處理。
</li>
<li>
<strong>基礎的設計原則</strong> ，無需完全掌握23種經典設計模式，只需要了解一些常用的設計原則即可，甚至你也可以只了解什么是低耦合，并在你的代碼中堅持實踐，也能寫出很不錯的代碼。
</li>
</ul>
<h2>
2. 代碼標準
</h2>
<p>
代碼標準在團隊合作中尤為重要，誰也不希望一個項目中代碼風格各異，看得讓人糟心，即便是個人開發者，現在也需要跟各種開源項目打交道。標準怎么定是一個老生常談的話題，我個人職業生涯中經歷過很多次的代碼標準討論會議，C++, C#, Java等等，大家有時會堅持自己的習慣不肯退讓。可現如今時代不一樣了，Google等大廠已經為我們制定好了各種標準，不用爭了，就用這些業界標準吧。
</p>
<h2>
3. 想好再寫
</h2>
<p>
除非你很清楚你要怎么做，否則我不建議邊做邊想。 <br />
你真的搞清楚你要解決的問題是什么了嗎？你的方案是否能有效？有沒有更優雅簡單的方案？準備怎么設計它，必要的情況下，需要有設計文檔，復雜一些的設計需要有同行評審，寫代碼其實是很簡單的事情，前提是你得先想清楚。 </p>
4. 代碼重構
</h2>
<p>
重構對于代碼質量的重要性不言而喻，反正我是很難一次把代碼寫得讓自己滿意、無可挑剔，《重構》這本書作為業內經典也理應人人必讀，也有其他類似的教授重構技巧的書，有些也非常不錯，遺憾的是我發現很多工作多年的同學甚至都沒有了解過重構的概念。
</p>
<h2>
5. 技術債務
</h2>
<p>
知乎上最近有個熱門問題《為什么有些大公司技術弱爆了?》，其實里面提到的很多歸根結底都是技術債務問題，這在一些大公司尤為常見。技術債務話題太大，但就代碼質量而言，我只想提一下不要因為這些債是前人留下的你就不去管，現實是沒有多少機會讓你從一個清爽清新的項目開始做起，你不得不去面對這些，你也沒法完全不跟這些所謂的爛代碼打交道。
</p>
<p>
因此我建議各位：當你負責一個小模塊時，除了把它做好之外，也要順便將與之糾纏在一起的技術債務還掉，因為這些債務最終將是整個團隊來共同承擔，任何一個人都別想獨善其身，如果你還對高質量代碼有追求的話。
</p>
<p>
作為團隊的技術負責人，也要頂住壓力，鼓勵大家勇于做出嘗試，引導大家不斷改進代碼質量，不要總是畏手畏腳，停滯不前，真要背鍋也得上，要有擔當。
</p>
<h2>
6. 代碼審查
</h2>
<p>
我曾經聽過一些較高級別的技術分享，竟然還不時聽到一些呼吁大家要做代碼審查的主題，我以為在這個級別的技術會議上，不應再討論代碼審查有什么好，為什么要做代碼審查之類的問題。同時我接觸過相當多所謂國內一線互聯網公司，竟有許多是不做代碼審查的，這一度讓我頗為意外。
</p>
<p>
這里也不想多談如何做好代碼審查，只是就代碼質量這點，不客氣地說：沒有過代碼審查經歷的同學，往往很難寫出高質量的代碼，尤其是在各種追求速度的糙快猛創業公司。
</p>
<h2>
7. 靜態檢查
</h2>
<p>
很多代碼上的問題，都可以通過一些工具來找到，某些場景下，它比人要靠譜得多，至少不會出現某些細節上的遺漏，同時也能有效幫助大家減少代碼審查的工作量。
</p>
<p>
Android開發中有Lint, Find bugs, PMD等優秀靜態檢查工具可用，通過改進這些工具找出的問題，就能對語法的細節，規范，編程的技巧有更多直觀了解。
</p>
<p>
建議最好與持續集成(CI)，代碼審查環境配套使用， 每次提交的代碼都能自動驗證是否通過了工具的代碼檢查，通過才允許提交。
</p>
<h2>
8. 單元測試
</h2>
<p>
Android單元測試，一直備受爭議，主要還是原生的測試框架不夠方便，每跑一次用例需要在模擬器或者真機上運行，效率太低，也不方便在CI環境下自動構建單元測試，好在有Robolectric，能幫我們解決部分問題。
</p>
<p>
單元測試的一個非常顯著的優點是，當你需要修改大量代碼時，盡管放心修改，只需要保證單元測試用例通過即可，無需瞻前顧后。
</p>
<h2>
9. 充分自測
</h2>
<p>
有一種說法：程序員最害怕的是他自己寫的代碼，尤其是準備在眾人面前show自己的工作成果時，因此在寫完代碼后，需要至少跑一遍基本的場景，一些簡單的異常流。在把你的工作成果提交給測試或用戶前，充分自測是基本的職業素養，不要總想著讓測試幫你找問題，隨便用幾下就Crash的東西，你好意思拿給別人嗎？
</p>
<h2>
10. 善用開源
</h2>
<p>
并非開源的東西，質量就高，但至少關注度較高，使用人數較多，口碑較好的開源項目，質量是有一定保證的，這其中的道理很簡單。即便存在一些問題，也可以通過提交反饋，不斷改進。最重要的是，你自己花時間造的輪子，需要很多精力維護，而充分利用開源項目，能幫助你節省很多時間，把精力專注在最需要你關心的問題上。
</p>
<p>
從另一個方面來說，開源項目中的一些知名項目，往往是領域內的翹楚所寫，學習這些高手的代碼，能讓你了解到好的代碼應該是怎樣的，培養出更靈敏的嗅覺，識別代碼中的各種味道。
</p>
4. 代碼重構
</h2>
<p>
重構對于代碼質量的重要性不言而喻，反正我是很難一次把代碼寫得讓自己滿意、無可挑剔，《重構》這本書作為業內經典也理應人人必讀，也有其他類似的教授重構技巧的書，有些也非常不錯，遺憾的是我發現很多工作多年的同學甚至都沒有了解過重構的概念。
</p>
<h2>
5. 技術債務
</h2>
<p>
知乎上最近有個熱門問題《為什么有些大公司技術弱爆了?》，其實里面提到的很多歸根結底都是技術債務問題，這在一些大公司尤為常見。技術債務話題太大，但就代碼質量而言，我只想提一下不要因為這些債是前人留下的你就不去管，現實是沒有多少機會讓你從一個清爽清新的項目開始做起，你不得不去面對這些，你也沒法完全不跟這些所謂的爛代碼打交道。
</p>
<p>
因此我建議各位：當你負責一個小模塊時，除了把它做好之外，也要順便將與之糾纏在一起的技術債務還掉，因為這些債務最終將是整個團隊來共同承擔，任何一個人都別想獨善其身，如果你還對高質量代碼有追求的話。
</p>
<p>
作為團隊的技術負責人，也要頂住壓力，鼓勵大家勇于做出嘗試，引導大家不斷改進代碼質量，不要總是畏手畏腳，停滯不前，真要背鍋也得上，要有擔當。
</p>
<h2>
6. 代碼審查
</h2>
<p>
我曾經聽過一些較高級別的技術分享，竟然還不時聽到一些呼吁大家要做代碼審查的主題，我以為在這個級別的技術會議上，不應再討論代碼審查有什么好，為什么要做代碼審查之類的問題。同時我接觸過相當多所謂國內一線互聯網公司，竟有許多是不做代碼審查的，這一度讓我頗為意外。
</p>
<p>
這里也不想多談如何做好代碼審查，只是就代碼質量這點，不客氣地說：沒有過代碼審查經歷的同學，往往很難寫出高質量的代碼，尤其是在各種追求速度的糙快猛創業公司。
</p>
<h2>
7. 靜態檢查
</h2>
<p>
很多代碼上的問題，都可以通過一些工具來找到，某些場景下，它比人要靠譜得多，至少不會出現某些細節上的遺漏，同時也能有效幫助大家減少代碼審查的工作量。
</p>
<p>
Android開發中有Lint, Find bugs, PMD等優秀靜態檢查工具可用，通過改進這些工具找出的問題，就能對語法的細節，規范，編程的技巧有更多直觀了解。
</p>
<p>
建議最好與持續集成(CI)，代碼審查環境配套使用， 每次提交的代碼都能自動驗證是否通過了工具的代碼檢查，通過才允許提交。
</p>
<h2>
8. 單元測試
</h2>
<p>
Android單元測試，一直備受爭議，主要還是原生的測試框架不夠方便，每跑一次用例需要在模擬器或者真機上運行，效率太低，也不方便在CI環境下自動構建單元測試，好在有Robolectric，能幫我們解決部分問題。
</p>
<p>
單元測試的一個非常顯著的優點是，當你需要修改大量代碼時，盡管放心修改，只需要保證單元測試用例通過即可，無需瞻前顧后。
</p>
<h2>
9. 充分自測
</h2>
<p>
有一種說法：程序員最害怕的是他自己寫的代碼，尤其是準備在眾人面前show自己的工作成果時，因此在寫完代碼后，需要至少跑一遍基本的場景，一些簡單的異常流。在把你的工作成果提交給測試或用戶前，充分自測是基本的職業素養，不要總想著讓測試幫你找問題，隨便用幾下就Crash的東西，你好意思拿給別人嗎？
</p>
<h2>
10. 善用開源
</h2>
<p>
并非開源的東西，質量就高，但至少關注度較高，使用人數較多，口碑較好的開源項目，質量是有一定保證的，這其中的道理很簡單。即便存在一些問題，也可以通過提交反饋，不斷改進。最重要的是，你自己花時間造的輪子，需要很多精力維護，而充分利用開源項目，能幫助你節省很多時間，把精力專注在最需要你關心的問題上。
</p>
<p>
從另一個方面來說，開源項目中的一些知名項目，往往是領域內的翹楚所寫，學習這些高手的代碼，能讓你了解到好的代碼應該是怎樣的，培養出更靈敏的嗅覺，識別代碼中的各種味道。
</p>
</div>
來自： http://www.linuxeden.com/html/news/20151230/164160.html
本文由用戶 jopen 自行上傳分享，僅供網友學習交流。所有權歸原作者，若您的權利被侵害，請聯系管理員。
轉載本站原創文章，請注明出處，并保留原始鏈接、圖片水印。
本站是一個以用戶分享為主的開源技術平臺，歡迎各類分享！