閱讀離職程序員遺留下來的垃圾源代碼是怎樣一種體驗？

一個service類兩萬行代碼、一個方法六七百行、if else嵌套如十八層地獄般深厚、方法傳參全是JSON，返回都HashMap<String, Object>，單是依賴注入的其他服務類代碼就達400行，小200個注入！

接下來讓我們一起來體驗這個神奇的“垃圾源代碼”！

返回參數是HashMap，傳參數是JSON，然后反序列化為HashMap對象：

這就是牛逼的“面向過程編程”，你說你維護的時候，你怎么知道他傳的啥？根據各種參數條件然后再返回啥？

硬著頭皮看代碼吧，這時候你發現這個方法3341-2657=684行代碼，再來看看他的if else嵌套：

按照sonarLint的方法復雜度計算，這段代碼的復雜度是116，這還只是這個方法中的“一小段”代碼。要知道sonarLint默認規則是只要這個方法的復雜度超過15就提示需要優化了！

看這個類的Annotate，竟然前前后后有幾十人維護過，恨不得一個類搞定所有業務，idea提示器從頭到尾都是黃色警告，更不用說集成阿里規約掃描插件甚至solarLint插件來掃描代碼了。。。

崩潰么？程序員的崩潰就在這一瞬間～

你說這樣的代碼讓你來維護是怎樣的一種體驗？

有時候不得不感慨，一個產品的成功與否，與代碼質量無關～

那么問題來了，程序員寫出一手漂亮可維護的代碼真的就這么難？

我覺得寫代碼本身不難，大多數都是在寫業務代碼，難得是自己心中沒有好代碼的標準，有的程序員知道自己寫的代碼不好，但是不知道怎么寫出好的代碼，這是問題存在的本因，你同意嗎？

這里我給出我個人覺得寫出可維護代碼的一些方法論：

1、不要用設計模式去實現業務代碼，越復雜越不可維護；

2、多看書，讀書破萬卷，下筆如有神。比如Java的可以看《阿里巴巴Java開發手冊》、《重構-改善既有代碼的設計》等；

3、去sonarqube官網學習一下sonarqube，他的代碼檢查rule等；

4、從今天起，在你的idea上裝上阿里巴巴Java規約掃描插件，讓你寫的每一個Java類沒有一個警告（還有更嚴格的sonarLint插件哦～）；

短期依賴工具迅速提高自己的代碼質量，長期持續學習閱讀相關技術書籍！

長此以往，你的代碼一定是可閱讀和可維護的，還有一個更大的好處就是：“你的代碼寫完了，基本上可以一次性自測通過！”