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