最近經常做業務邏輯程式碼review的工作，發現各種風格的程式碼，其中有一種是封裝和抽象做的非常的多，程式碼層次非常的深入，表面給人感覺是：牛逼的程式碼。但是從清晰度和可維護性來說，還是不推薦這麼做。
1、這種程式碼出現問題後，很難定位哪裡出現問題;
2、後續別人維護起來也相當困難;
3、每看一個簡單的case，都要跟蹤很久;
4、寫UT（單元測試）也相當麻煩
我個人認為編寫業務邏輯程式碼還是要從可讀性入手，輕鬆的能看懂程式碼，如果程式碼有問題，可以快速定位和修復。我們又不是做底層框架編寫，要追求各種設計和擴充套件性。
下面列舉我覺得是清晰可維護的業務邏輯程式碼的一些特性。
清晰
雖然物件導向講究內聚和封裝，但是太多的子方法和類，實在是會把人繞到頭暈，我推薦的做法是，方法儘量的內聯，是同一個業務的就通通放到某個方法裡面，如果這段邏輯實在太長，可以考慮抽取一些子方法(儘量別太多)。至於類，別動不動就來個類封裝一把，要避免類膨脹。
好的命名和註釋
現在網上的一些文章流行去除所有註釋，通通用一個好的方法名字表達即可。這種做法我個人是很反對的。雖然方法的命名極其重要，但是寫業務邏輯程式碼，必要的註釋還是要的，另外的同事閱讀程式碼的時候，也比較容易讀懂程式碼的意圖。
精準有意義的日誌輸出
如果從事過網際網路專案的同學，應該有一種深深的體會，線上出現問題，除了看各種監控系統之外，就是看日誌了。日誌的輸出必須是有意義準確的，尤其是異常日誌和業務日誌。好的日誌輸出，可以快速定位問題並快速解決。如果解決一個問題要一個小時的話，有可能公司就損失幾百萬了。
程式碼對稱性
例如:
|
1 2 3 4 5 |
getInputParameter(); process(); output(); |
這種就屬於程式碼的對稱性。
必要的設計
只是簡單的根據業務場景直白的編寫程式碼也是不可行的。必要的設計可以帶來更加清晰的程式碼結構。
一定要有UT（單元測試）
沒有UT的程式碼實在是太恐怖了，尤其是網際網路應用的程式碼，稍微出點問題，公司就有可能損失一大筆錢。
編寫ut的時候，至少一定要把重要的流程覆蓋到，萬一程式碼有問題了，也只是小問題。再者，由於需求的變更，原來寫好的程式碼還需要再次改動，如果你沒有ut覆蓋的話，可能影響原來程式碼的功能。ut可以帶給我們信心。另外UT也可以促進你編寫清晰的程式碼。
打賞支援我寫出更多好文章，謝謝！
打賞作者
打賞支援我寫出更多好文章，謝謝！
