最近來到新的項目組，接手了一個離職員工的代碼，閱讀后感覺有較大的優化改進空間，於是乎着手調整，誰知，開始時調整的還挺有成就感，可是后面真的會越來越感覺到痛苦了，開始理解了為什么很多老員工寧願哪里出問題去補哪里也不願意做出大調整的心理了！
今天下了班，但是在想着那個模塊的代碼，怎么會寫成這樣？怎么簡化/優化/優雅？
夜深了，在床上也就梳理下思想。
細節的簡化:
1.數據庫交互相關方法簡化
舊版:一個SQL操作需要一個方法，一個方法三四十行的一個大代碼塊，不同方法間代碼重復率很高，整體看來代碼非常冗余。
新版:抽出SQL語句，方法題重復的部分工具化，用的時候就傳個SQL拿返回值。
2.分支判斷內代碼冗余
if塊內和else塊內有大量的重復代碼，可以提出到判斷外，判斷塊內只需要放不同條件的執行語句。
代碼結構調整
模塊化
舊版:All in One 幾乎全部東西都在一個類里，沒有分層化、模塊化，在分析代碼的時候，有時候從十幾行跳到幾十行，又跳到幾百行，甚至兩千行，又跳到第四五百行，不是太好閱讀，不利於團隊其他成員接手，不利於問題排查和維護。
文件操作，數據庫操作，業務處理 柔和在一起，一個方法操作數據庫的方法又帶有去寫文件的代碼，耦合度相當高，代碼分析、維護、他人接手都會帶來一定的難度。
語義化
對於非直接暴露的變量名、方法名、類名，在命名上不至於要簡潔到一兩個字母代表一個含義吧😄，ge是啥？太簡寫了后面接手的人理解成本高啊，名字寫全點通俗點可能會長一點，但是理解起來很方便。
特例？有些方法叫getxxxxxx，但是返回類型是void，方法里執行的效果是生成文件，叫createxxxxxxx不更好嗎
簡化
分層/分包/模塊化/降低耦合/去除冗余:
業務層 :主要業務的處理
數據層:與數據庫交互，返回數據結果
工具包:文件類、時間類
總之，就是應該通過規范化，降低他人在代碼理解上花的成本，通過規范化，降低問題排查，代碼升級維護所需要的成本。