寫出高質量程式碼的10個建議

發表於2015-12-30

很長一段時間以來,我都在關注如何提高程式碼質量,也為此做過一些嘗試,我想這個話題可能大家會比較感興趣,在這裡分享一下我關於如何提高程式碼質量的一些體會。

1. 打好基礎

寫出高質量程式碼,並不是搭建空中樓閣,需要有一定的基礎,這裡我重點強調與程式碼質量密切相關的幾點:

  • 掌握好開發語言,比如做Android就必須對Java足夠熟悉,《Effective Java》一書就是教授大家如何更好得掌握Java, 寫出高質量Java程式碼。
  • 熟悉開發平臺, 不同的開發平臺,有不同的API, 有不同的工作原理,同樣是Java程式碼,在PC上寫與Android上寫很多地方不一樣,要去熟悉Android程式設計的一些特性,iOS程式設計的一些特性,瞭解清楚這些,才能寫出更加地道的程式碼,充分發揮各自平臺的優勢。
  • 基礎的資料結構與演算法,掌握好這些在解決一些特定問題時,可以以更加優雅有效的方式處理。
  • 基礎的設計原則,無需完全掌握23種經典設計模式,只需要瞭解一些常用的設計原則即可,甚至你也可以只瞭解什麼是低耦合,並在你的程式碼中堅持實踐,也能寫出很不錯的程式碼。

2. 程式碼標準

程式碼標準在團隊合作中尤為重要,誰也不希望一個專案中程式碼風格各異,看得讓人糟心,即便是個人開發者,現在也需要跟各種開源專案打交道。標準怎麼定是一個老生常談的話題,我個人職業生涯中經歷過很多次的程式碼標準討論會議,C++, C#, Java等等,大家有時會堅持自己的習慣不肯退讓。可現如今時代不一樣了,Google等大廠已經為我們制定好了各種標準,不用爭了,就用這些業界標準吧。

3. 想好再寫

除非你很清楚你要怎麼做,否則我不建議邊做邊想。
你真的搞清楚你要解決的問題是什麼了嗎?你的方案是否能有效?有沒有更優雅簡單的方案?準備怎麼設計它,必要的情況下,需要有設計文件,複雜一些的設計需要有同行評審,寫程式碼其實是很簡單的事情,前提是你得先想清楚。

4. 程式碼重構

重構對於程式碼質量的重要性不言而喻,反正我是很難一次把程式碼寫得讓自己滿意、無可挑剔,《重構》這本書作為業內經典也理應人人必讀,也有其他類似的教授重構技巧的書,有些也非常不錯,遺憾的是我發現很多工作多年的同學甚至都沒有了解過重構的概念。

5. 技術債務

知乎上最近有個熱門問題《為什麼有些大公司技術弱爆了?》,其實裡面提到的很多歸根結底都是技術債務問題,這在一些大公司尤為常見。技術債務話題太大,但就程式碼質量而言,我只想提一下不要因為這些債是前人留下的你就不去管,現實是沒有多少機會讓你從一個清爽清新的專案開始做起,你不得不去面對這些,你也沒法完全不跟這些所謂的爛程式碼打交道。

因此我建議各位:當你負責一個小模組時,除了把它做好之外,也要順便將與之糾纏在一起的技術債務還掉,因為這些債務最終將是整個團隊來共同承擔,任何一個人都別想獨善其身,如果你還對高質量程式碼有追求的話。

作為團隊的技術負責人,也要頂住壓力,鼓勵大家勇於做出嘗試,引導大家不斷改進程式碼質量,不要總是畏手畏腳,停滯不前,真要背鍋也得上,要有擔當。

6. 程式碼審查

我曾經聽過一些較高階別的技術分享,竟然還不時聽到一些呼籲大家要做程式碼審查的主題,我以為在這個級別的技術會議上,不應再討論程式碼審查有什麼好,為什麼要做程式碼審查之類的問題。同時我接觸過相當多所謂國內一線網際網路公司,竟有許多是不做程式碼審查的,這一度讓我頗為意外。

這裡也不想多談如何做好程式碼審查,只是就程式碼質量這點,不客氣地說:沒有過程式碼審查經歷的同學,往往很難寫出高質量的程式碼,尤其是在各種追求速度的糙快猛創業公司。

7. 靜態檢查

很多程式碼上的問題,都可以通過一些工具來找到,某些場景下,它比人要靠譜得多,至少不會出現某些細節上的遺漏,同時也能有效幫助大家減少程式碼審查的工作量。

Android開發中有Lint, Find bugs, PMD等優秀靜態檢查工具可用,通過改進這些工具找出的問題,就能對語法的細節,規範,程式設計的技巧有更多直觀瞭解。

建議最好與持續整合(CI),程式碼審查環境配套使用, 每次提交的程式碼都能自動驗證是否通過了工具的程式碼檢查,通過才允許提交。

8. 單元測試

Android單元測試,一直備受爭議,主要還是原生的測試框架不夠方便,每跑一次用例需要在模擬器或者真機上執行,效率太低,也不方便在CI環境下自動構建單元測試,好在有Robolectric,能幫我們解決部分問題。

單元測試的一個非常顯著的優點是,當你需要修改大量程式碼時,儘管放心修改,只需要保證單元測試用例通過即可,無需瞻前顧後。

9. 充分自測

有一種說法:程式設計師最害怕的是他自己寫的程式碼,尤其是準備在眾人面前show自己的工作成果時,因此在寫完程式碼後,需要至少跑一遍基本的場景,一些簡單的異常流。在把你的工作成果提交給測試或使用者前,充分自測是基本的職業素養,不要總想著讓測試幫你找問題,隨便用幾下就Crash的東西,你好意思拿給別人嗎?

10. 善用開源

並非開源的東西,質量就高,但至少關注度較高,使用人數較多,口碑較好的開源專案,質量是有一定保證的,這其中的道理很簡單。即便存在一些問題,也可以通過提交反饋,不斷改進。最重要的是,你自己花時間造的輪子,需要很多精力維護,而充分利用開源專案,能幫助你節省很多時間,把精力專注在最需要你關心的問題上。

從另一個方面來說,開源專案中的一些知名專案,往往是領域內的翹楚所寫,學習這些高手的程式碼,能讓你瞭解到好的程式碼應該是怎樣的,培養出更靈敏的嗅覺,識別程式碼中的各種味道。

相關文章