提高代碼的可讀性

開發人員需要花費大量的時間閱讀代碼，甚至超過了撰寫代碼的時間，這里我所說的閱讀包括以下作業：除錯代碼、檢查他人提交的代碼、學習新的代碼庫等等，

因此，你應該確保自己的代碼便于閱讀，即便有的時候你需要更長的命名、撰寫更多代碼，以及舍棄自己的“小聰明”，

舉個例子，雖然變數名 timeInMillis 比 time 更長，你需要輸入的字符也更多，但是開發人員無需查看其他代碼就能明白這個變數計算的是哪種時間，

再舉一個例子，網上有很多一行代碼的解決方案，例如，如下判斷回文數的寫法非常聰明（注：回文數指的是像 14641 這樣“對稱”的數，即：將這個數的數字按相反的順序重新排列后，所得到的數和原來的數一樣）：

def isPalindrome(self, x: int) -> bool:
   a=list(str(x))    return a==a[::-1]

但是，非常難以理解，一行代碼的解決方案很有挑戰性，不建議在多人共同維護的代碼庫中采用這種寫法，

重構的價值

只有當重構幫助你和團隊成員節省的時間超過重構花費的時間，才值得投入，你應該將精力集中到頻繁閱讀和撰寫的代碼上，

你可以考慮，將不緊急的重構分配給新來的團隊成員練手，這樣他們不但有機會學習，同時也能貢獻價值，

將技術負債視作財務負債，可以適量承擔一些

有時，從業務的角度出發，盡快提供有價值的功能可以獲取更大利益，比如趕在競爭對手發布類似的功能之前，即使這個時候的功能還不夠完美也沒關系，只要你可以建立計劃，趕在債臺高筑，被“利息”壓得透不過氣來之前，及時地改善代碼，

如果技術負債的積累速度超過你的償還能力，那么就會出現問題，代碼庫的處理難度就會越來越大，

例如，在時間緊迫的情況下，在完成測驗之前就發布某項功能也可能是正確的業務決策，但是事后你需要立即補上測驗，如果你拖延測驗，很快這些未測驗的代碼之上就會出現新的代碼，未經測驗就發布的功能也會相繼出現，那么償還這部分技術負債的難度就會越來越大，很難再還給團隊一個維護良好的代碼庫，

不要制造驚喜

團隊成員會假定你的代碼遵循常見的慣例，所以你不應該偏離這些慣例，不要給他們制造驚喜，

例如，如果你撰寫了一個函式 isButtonEnabled()，那么團隊成員肯定會假定這個函式是在檢查某個按鈕，它會回傳一個布林值，因為絕大多數的這類函式名稱都以“is-”開頭，如果你的函式還做了其他處理，那么就應該在名稱中澄清，

命名的長度應該視范圍而定

例如，for 回圈中可以使用 i 和 j 之類的變數名，但是全域常量的名稱應該更加精準地表達它的意圖，

函式也需要保證可讀性，而不僅僅是為了避免重復

一般，我們常說重復三次以上的代碼都應該寫成函式，但我還想再加兩點應該寫成函式的情況：

1）當需要添加注釋解釋這段代碼的用途的時候；

2）當嵌套超過3層的時候，

舉個例子，假設我撰寫了下列UI函式：

fun setupViews() {// set up textView
   textView.isVisible = …
   textView.text = …
   …more textView setup…// set up imageView
   imageView.image = …
   imageView.backgroundColor = …
   …more imageView setup…
}

我們應該將相應的代碼分別放入另外兩個函式 setupTextView() 和 setupImageView()，即便它們不包含重復代碼，

通過這種方式撰寫出來的代碼，本身就可以作為檔案，如果有人需要修改或除錯 imageView，他可以直接去 setupImageView()，而無需閱讀所有的代碼，

另一個常見的情況是關于函式的最大代碼行數，這個值的設定非常隨意，通常在5～100的范圍內，我個人認為基本的標準是：閱讀函式的時候不需要翻頁，

重復的呈現形式有很多種

DRY（Don't repeat yourself，不要重復你自己）是一個眾所周知的軟體工程原則，最常見的重復就是完全相同的代碼，但是也有一些重復的形式并沒有那么明顯，例如實作的重復，

舉個例子，對于如下定義的類：

class TreeNode {
    val value: String
    var children: List<TreeNode>
    val isLeaf: Boolean        fun addChild(node: TreeNode) {
       children.add(node)
       isLeaf = false
   }
    
    fun removeChild(node: TreeNode) {
        children.remove(node)        if (children.isEmpty()) isLeaf = true
   }
}

不需要在每次 child 更新的時候設定 isLeaf， 你可以添加 fun isLeaf() = children.isEmpty()，如此一來，在更新這個類的時候，你就無需檢查 isLeaf 是否被更新了，

不要重復其他人的作業

在實作某個功能之前，首先你應該先檢查一下代碼庫中是否已有現成的實作，

例如，你需要處理時間，常量 SECONDS_PER_MINUTE 可能已經存在了，你可以直接重用，而不應該在同一個代碼庫中多次定義這個常量，

學習并遵守專案的編程風格

一套統一的開發指南可以方便團隊成員理解彼此的代碼，也可以方便新來的成員，通常，實際的規則并不重要，重要的是你需要確保這些規則被貫徹執行了，例如，我曾見過一些 Kotlin，所有包含擴展函式的檔案名都以“-Ext”結尾，而其他檔案則使用“-s”結尾，實際的選擇并不重要，重要的是所有人的選擇必須統一，只有這樣程式員才知道哪里能找到 Foo 的擴展函式，是在 FooExt.kt 中還是在 Foos.kt 中？

通過 lint 規則提升代碼的整潔度

如果你在專案中使用了lint工具，而且你經常手動調整格式，或者在代碼審核時經常有人提出格式方面的建議，那么就應該考慮一下增加一條新的lint規則，

學習使用 IDE

現代 IDE（比如Android Studio 和 VSCode）非常強大，你應該學習如何使用 IDE 的各種小工具（比如除錯器），以及鍵盤快捷鍵，雖然這需要投入一定的時間，但從長遠打算來看能夠為你節省很多時間，

你應該自定義設定和鍵盤快捷鍵，優化你的作業流程，例如，JetBrains IDE 默認不提供“Split editor tab”的快捷鍵（你必須點擊Window → Editor Tabs → Split Vertically），但是我添加了一個自定義的快捷鍵，因為我經常使用，

注釋應該解釋原因，而不是實作方式

理想情況下，代碼應該不言自明，不需要添加注釋，程式員在修改代碼的時候，經常忽略更新注釋，時間久了，注釋就會不準確，與實際的代碼大相徑庭，在你打算寫注釋，解釋代碼的功能時，不妨考慮一下重構代碼，讓代碼不言自明，

然而，僅靠代碼自身還不足以解釋為什么你選擇這種方式，注釋可以提供背景關系，比如幫助你做出決策的產品需求、系統限制或出于效率的考慮，

不要將測驗代碼視作二等公民

在撰寫生產代碼的時候，你可能需要花點時間計劃代碼，確保在功能發布之前達到良好的品質，但是程式員通常都會忽視測驗代碼，只要能正常運行就可以了，然而，測驗代碼也需要維護，如果這些代碼很難理解，那么就會增加維護的負擔，

部分問題是測驗代碼一般都不需要經過嚴格的審核，大家會花費大量時間審核生產代碼，卻覺得測驗代碼沒這個必要，因為畢竟已經通過了測驗，

表格驅動測驗

幾個月以前，我發現了Junit的引數化測驗，這種方法幫助我撰寫了更多徹底的測驗，

在常規單元測驗中，通常每個輸入只有一個測驗函式，最后會導致很多函式都有重復的代碼，而且很容易漏掉一些輸入，表格驅動測驗有一個單獨的測驗函式，還有一個表格囊括了所有可能的輸入以及預想的輸出，只需要一個測驗函式，就可以測驗所有輸入，

采用新庫有風險

每個庫都有預發布的版本，很有可能會破壞已有的功能，

在新發布的庫中，易于測驗可能是次要考慮因素，如果你想在大型專案中采用新庫，事先必須驗證這些庫是否能夠通過你的測驗代碼，并兼容生產代碼，

在社區廣泛采納某個庫之前，遇到問題時，很難找到資源，而且可能這個庫永遠也不會被廣泛采納，專案本身也會被維護人員遺忘，

對于有些庫，看似每個人都在使用，但是真正的專案中采用了這些庫嗎？還是說只是出現在演示程式中？

向團隊成員尋求幫助時，應該注意他們的方法，而不只是解決方案

注意團隊成員使用的資源和工具，如果將來再遇到類似的問題，你能夠更好地武裝自己，靠自己的力量解決問題，發現新的資源和工具都很有價值，比如文黨澩、Git命令、鍵盤快捷鍵等，

審核人員對代碼變更感到不解或產生誤解，則說明代碼有問題

除了回應審核意見之外，你應該考慮重構或添加注釋來澄清，這樣可以確保將來其他人閱讀這段代碼的時候，不會遇到同樣的困惑，

閱讀代碼審核意見

當你在理解某段代碼時遇到困難，則應該仔細閱讀代碼的審核意見，從代碼的審核意見可以看出，同時間內還有哪些代碼發生了變化，因此閱讀這些審核意見很有價值，而且其中還可能包含代碼背后的決策說明，

如果你正在實作的某個功能與某個已有的功能非常相似，那么閱讀相似功能的代碼審核意見，可以幫助你規劃自己的實作，例如，如果我想添加某個Android 功能，但iOS或Web已有這個功能，則看看其他平臺的實作方法會有很有幫助性，

按照自己喜歡的方式學習

上大學的時候，除了課堂上的學習之外，你的知識主要來自自己的業余專案，在找作業的時候，這些經驗會幫助你脫穎而出，但是，在之后的作業中，如果你想跳槽，則與自己的業余專案相比，實際作業專案的經驗更能贏得面試官的青睞，

在業余專案中，你可以做自己喜歡做的事情，當然你可以繼續享受這些專案！但是，除此之外，還有很多其他的學習方式：閱讀博客、看演講、參加在線課程、聽播客等等，你可以找到自己最喜歡的方式，或者你也可以利用作業之外的時間發展其他興趣愛好，

在線資源的質量層次不齊

任何人都可以通過互聯網發表技術博客文章，如果你打算通過某篇博客文章學習新技術，卻發現其中的內容不太合理，那么可能只是因為文章本身寫得不怎樣，你不必就此放棄，而是應該嘗試其他資源，

官方的資源和教程通常都是很好的切入點，會議演講以及公司的技術博客的質量一般也都比較高，因為這些資源都經過了嚴格的審查，

最后

說到學習資源，以下是我常去的一些網站，本文提及的很多準則也正是來自這些資源：

• Refactoring Guru：一個網站，介紹了如何撰寫和重構整潔的代碼，

• Clean Code：經典的軟體工程書籍，有些內容有點過時，而且還與Refactoring Guru有重疊，但是仍然值得一讀，

• Martin Fowler’s website：作者撰寫了很多有關軟體開發的書籍，而且他的網站也有很多關于軟體架構與重構的資訊，

• Android Weekly newsletter：一份周刊，精選了很多技術文章、播客以及演講，僅限于Android，但是其他平臺也有類似的周刊，

• Yelp Android school：科技演講GitHub存盤庫，有一半是Android為主，還有一半討論的是軟體工程，

如果你還想了解更多編程知識，詳情點擊下方了解更多噢~《+Q群：1151395975》

標籤：其他

上一篇：論一個資深程式員的成長史：干久了，怎么預防職業病癥？

下一篇：怎么實作軟體注冊碼功能？