原創聲明：該文章是個人在項目中親歷后的經驗總結和分享，如有搬運需求請注明出處。 這是“深入淺出系列”文章的第一篇，主要記錄和分享程序設計的一些思想和方法論，如果讀者覺得所有受用，還請“一鍵三連”，這是對我最大的鼓勵。

一、老生常談，到底啥是可讀性

一句話：見名知其義。有人說好的代碼必然有清晰完整的注釋，我不否認；也有人說代碼即注釋，是代碼簡潔之道的最高境界，我也不否認。但我都不完全接受，如果照搬前者，有人會在每個方法、每個循環、每個判斷都添加大量注釋，對于一個表達不嚴謹的coder來說，代碼與漢字可能詞不達意；而且，一旦代碼邏輯發生變化，注釋改不改？對于后者，英語水平可能也就是個半吊子，動詞名詞不區分，真能做到代碼即注釋的有多少人？

二、罵歸罵，總歸要硬著頭皮干

先來舉個簡單例子：

public StepExitEnum doExecute(StepContext stepContext) throws Exception {
    String targetFilePath = this.getOriginFilePath(stepContext.getJobContext());//獲取目標路徑
    File targetDir = new File(targetFilePath);
    if (!targetDir.exists()) {
        targetDir.mkdirs();//如果不存在目錄則創建
    }

    String encryptedFilePath = this.getEncryptedFilePath(stepContext.getJobContext());//獲取加密文件路徑
    String fileName = this.getFileName(stepContext);//獲取文件名
    File[] encryptedFiles = new File(encryptedFilePath).listFiles(this.buildFilenameFilter(fileName));//過濾文件

    FileEncryptor dencryptor = this.buildFileEncryptor(stepContext);//創建FileEncryptor
    Stream.of(encryptedFiles)
            .forEach(encryptFile -> {
                File targetFile = new File(targetFilePath, encryptFile.getName());
                dencryptor.invoke(encryptFile, targetFile);//解密文件
            });

    return StepExitEnum.CONTINUING;
}

這種代碼很常見，耐著性子其實也容易看懂：創建目錄->讀取加密文件->解密文件，就當前來說其實滿足了業務需求也就可以了，但不夠優雅，從長期來講，這會產生bad smell，首先，“如果不存在目錄則創建”、“獲取文件名”這類注釋有何意義？有可能這是coder當時的方案思路，但這里真的需要嗎？它確確實實影響我的注意力了，但我沒有獲取到任何有價值信息；其次，若想要理解doExecute這個方法的目的，必須通讀代碼，而我只是想知道它做了什么事；最后，這個方法如果某一行出問題了，那么影響范圍是整個業務流程。

如果后期需要改動，大部分人可能會增加條件判斷，或是在后面繼續追加代碼實現，最后會導致越來越難以閱讀，這其實也就是“能運行就不要動它”這個梗的根源了，因為沒人能讀明白它到底做了什么，但又不得不改，同時可能伴隨著“口吐芬芳”。

三、意識先行，從一行做起

那么到底該如何做呢？下面是我的一個例子：

public StepExitEnum doExecute(StepContext stepContext) throws Exception {
    initTempFilePath(stepContext);
    File[] encryptedFiles = findEncryptedFiles(stepContext);
    dencryptFiles(encryptedFiles, stepContext);
    return StepExitEnum.CONTINUING;
}

先不論具體實現細節，是不是一眼看過之后就了解doExecute做了什么事？這個方法的確沒有任何注釋，是否影響閱讀？其實我做的只是把先前的代碼重新歸類，分別放到了三個方法中，核心實現還是原本的代碼，沒有改動，現在閱讀起來是不是順暢了許多？

通讀代碼后我發現其實只做了三件事：創建目錄、讀取加密文件、解密文件，這是最核心的三個步驟，把它抽象出來，獨立為方法，既表達了邏輯功能，也清晰閱讀，還可以縮小影響范圍，今后哪里有問題改哪里，不需要再通讀代碼了。

四、回到主題，再說可讀性

（1）抽象，合理的業務邏輯抽象

“一個方法只應該做一件事”，想必很多人聽過類似的表述，聽起來簡單做起來難，怎么定義“只做一件事”？這件事的邊界是什么？這就依賴coder對業務邏輯、對功能實現的深入理解和合理抽象，這才能清晰的區分出各個功能的邊界，或者說是如何定義這件“事”。

沒有基于業務的合理抽象，硬生生地寫了幾個方法，你會發現這幾個方法“藕斷絲連”，一個方法的參數變化總會影響到另一個方法，很難將一個方法單拎出來應用在其他場景，一處改，處處改，這時候就要考慮，方法抽象的是否合理？

合理的抽象，從功能角色、職責劃分上就很清晰，有了這個基礎，才能清晰的編寫業務邏輯代碼，而不是堆砌各種條件判斷和循環，同時帶著兩條斜杠和注釋，這是可讀性的基礎。

（2）各司其職，職責單一

一個方法只做一件事，擴展到一個類也如此，職責單一，歸根結底還得基于合理的抽象，所以，它其實是抽象的一種具體體現，二者總是相輔相成。

（3）命名規范

這也是老生常談了，但真正做到的coder其實不多，類名、方法、變量的命名規則其實很有講究，但這不是本文的主題，不多贅述，類名用名詞，方法名用動詞，因為類表述的是做什么事，而方法名表述的是如何做，規范的命名和正確的詞法，這是編碼的基礎功底，這會有助于他人閱讀代碼，當然也是為什么我們讀spring源碼會感覺順暢，而讀同事寫的業務代碼卻很蹩腳的原因，我們太過于強調spring的IOC了，卻忽略了最基礎的東西。

（4）關鍵注釋

注釋不能少，但也不應該每個方法、每個判斷、每個循環到處都是//和/*，畢竟代碼是主體不是注釋，而且這樣還會帶來隱性的工作量問題：代碼修改，注釋也必須修改。所以好的注釋不是多，是關鍵。例如java.util.HashMap類的注釋上會告訴你線程安全問題：

Note that this implementation is not synchronized.

這是很關鍵的信息，所以注釋要給出關鍵性的、使用上注意的事項，不在于多。

代碼可讀性其實是一個比較寬泛的問題，也是一個老生常談的問題，隨著編碼經驗積累，在不同職業階段，我們對可讀性都會有不同的理解和認識，本文從我自己的角度和經驗，討論了一些比較淺的理解，如何寫出易讀、易懂的優秀代碼，可能是我們coder永遠追尋的目標之一，即使它沒有終點。

?

最后別忘了“一鍵三連”！


審核編輯 黃宇