最近經常做業務邏輯代碼review的工作，發現各種風格的代碼，其中有一種是封裝和抽象做的非常的多，代碼層次非常的深入，表面給人感覺是：牛逼的代碼。

但是從清晰度和可維護性來說，還是不推薦這么做，理由如下：

• 這種代碼出現問題后，很難定位哪里出現問題
• 后續別人維護起來也相當困難
• 每看一個簡單的case，都要跟蹤很久
• 寫UT（單元測試）也相當麻煩

我個人認為編寫業務邏輯代碼還是要從可讀性入手，輕松的能看懂代碼，如果代碼有問題，可以快速定位和修復。我們又不是做底層框架編寫，要追求各種設計和擴展性。

下面列舉我覺得是清晰可維護的業務邏輯代碼的一些特性。

清晰

雖然面向對象講究內聚和封裝，但是太多的子方法和類，實在是會把人繞到頭暈，我推薦的做法是，方法盡量的內聯，是同一個業務的就通通放到某個方法里面，如果這段邏輯實在太長，可以考慮抽取一些子方法(盡量別太多)。至于類，別動不動就來個類封裝一把，要避免類膨脹。

好的命名和注釋

現在網上的一些文章流行去除所有注釋，通通用一個好的方法名字表達即可。這種做法我個人是很反對的。雖然方法的命名極其重要，但是寫業務邏輯代碼，必要的注釋還是要的，另外的同事閱讀代碼的時候，也比較容易讀懂代碼的意圖。

精準有意義的日志輸出

如果從事過互聯網項目的同學，應該有一種深深的體會，線上出現問題，除了看各種監控系統之外，就是看日志了。日志的輸出必須是有意義準確的，尤其是 異常日志和業務日志。好的日志輸出，可以快速定位問題并快速解決。如果解決一個問題要一個小時的話，有可能公司就損失幾百萬了。

代碼對稱性

例如：

getInputParameter();
process();
output();

這種就屬于代碼的對稱性。

必要的設計

只是簡單的根據業務場景直白的編寫代碼也是不可行的。必要的設計可以帶來更加清晰的代碼結構。

一定要有UT（單元測試）

沒有UT的代碼實在是太恐怖了，尤其是互聯網應用的代碼，稍微出點問題，公司就有可能損失一大筆錢。

編寫ut的時候，至少一定要把重要的流程覆蓋到，萬一代碼有問題了，也只是小問題。再者，由于需求的變更，原來寫好的代碼還需要再次改動，如果你沒有ut覆蓋的話，可能影響原來代碼的功能。ut可以帶給我們信心。另外UT也可以促進你編寫清晰的代碼。

本文轉載自