一個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外掛哦～）；

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

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

入職一家公司，剛接觸專案程式碼時候給我人都看傻了。一個activity 6000多行，各種邏輯都放在裡面處理，if else 嵌套了1500行，新加個欄位能折騰半天。後來一問是外包寫的。

就發兩行讓大家開開眼吧

boolean flag=！(！(list==null) &&！(list.size()==0 ))

if(！flag){

}

有時候程式設計師也很無奈，比如剛新開發上線的功能可能過兩天後就要改版，然後發現要動很多地方，時間也很緊迫，需求就三個字：“明天要”，這種情況下你還考慮什麼整潔度、設計模式、程式碼抽離之類的，能在有限的時間內把業務程式碼堆完就不錯了，這種情況很無奈。等你回頭想最佳化程式碼時，發現根本沒時間而且程式碼越滾越大，已經無力修改了。

第一，這跟大多數公司要求相關，公司沒有這些規定時，每個程式設計師都有每個人的寫作風格，所以你也不必喯。第二，由於公司專案催得緊，在短時間內能夠實現功能都不錯了，你讓程式設計師怎麼給你規範寫程式碼呢？現在大多數公司最求的是短期利潤，所以很難有非常優質的程式碼的！第三，這與個人習慣有很大關係，大多數程式設計師都是自以為自己寫的程式碼是很好閱讀的，但是對於別人來說閱讀起來並不友好！

接手一個應用程式，是管理研發課題的。一個課題下面可以有若干項任務，每個任務有一個狀態status，狀態可以是待批，批准，進行中，完成，驗收合格等等。一個數據庫儲存過程非常慢，經常10分鐘以上才能得到結果，還經常半道死了。你結果對也行，還經常返回一些任務狀態不一致的課題，有bug。裡面用了十幾個query，沒有註釋，讀了兩小時愣是沒看懂它要幹什麼。結果課題經理說，如果一個課題下的所有任務的狀態相同，比如都是完成，那麼該課題就應該被返回，就是找出所有其全部任務都處於相同狀態的課題。我靠，這麼簡單的事？給他全改了，一個query，group by課題編號，having max(status) = min (status)，執行速度快得飛起，就沒有超過一秒鐘的時候。老闆嘴都笑歪了。我心想，你僱的都是什麼程式設計師吶，這程式碼寫的，好比解皮帶，蹲坑，起來，再把皮帶繫上，如此反覆多次，最後沒拉便便，放了一個pi，還是蔫兒臭的那種，沒法看。糟心大了。

不是垃圾程式碼，是多少個通宵打上去的補丁，雖然亂，但是解決了實際問題。實現過程也是需求穩定的過程，如果需求穩定後再開發，就不會這麼難看，這個鍋程式設計師不背

產生的原因基本是這樣的，老闆有上一任預留的爛程式碼，老闆不關心誰在做，只覺得快完成了，然後請一個人很簡單，半個月趕往三月的量，重構是不可能的，只能錯上加錯，特別是那些小老闆都把時間看得很緊....後面又進行不下去，就傳到你的手裡了...

經常遇到過！

1，資料呼叫，只看有資料，從不核對資料！

2，圖示統計，資料寫死，沒有動態呼叫！

3，sql語句已經有現成的預編譯框架，安全有效，卻硬生生的把預編譯整成原生的

4，資料庫表呼叫錯誤！

5，安全過濾直接跳過，用原生獲取！

。。。。。。

相對於垃圾程式碼，以上情況，又會是什麼體驗呢？“欲罷不能”，想瘋的心都有的

大家都不要罵程式設計師寫的程式碼負責看不懂，那是程式設計師為了保護自己。誰寫簡明扼要，一目瞭然的程式碼，誰是傻瓜。

程式設計師想成為不可缺少，不能替代的人，所以寫出天書程式碼，這是一種智慧財產權保護，類似於加密。

你是精明的程式設計師，還是傻子？精明的寫密碼，傻子謝明碼。

接手別人的辣雞程式碼工作很難避免，作為一個奮鬥一線的程式設計師說說感受吧。

面對一坨坨辣雞程式碼，心裡壓力肯定不小。

心裡默問，這哥們留的有沒有坑呢？如果上線出了bug我該如何處理呢？…，所有的一切都是未知，所以會緊張，萬一出了問題，一時半會搞不定多沒面子。會不會暴露自己水平很菜？

畢竟之前很長時間內做的都是自己熟悉的東西，萬一這個玩不轉，領導、同事怎麼看我？崇拜我技術牛逼的測試妹子又會怎麼想？

所以，問題會有很多。不過不管怎樣都得硬著頭皮去一塊一塊的去啃。

然後開始罵開，

這寫的什麼玩意程式碼？

這個實現方式這麼low？這哥們啥技術呀，會不會寫程式碼？

哎，真是一堆辣雞程式碼！還好遇到了我，有起死回生的技術，有時間給他重構吧！

嗯，也多虧是我接手這辣雞程式碼，換了其他人肯定得好幾個月也不一定搞的定。此時又信心爆崩…

哎，我還傻傻的曾經認為他是大神！就這程式碼效果簡直和小學生差不多呀。

算了，不吐槽了，就這樣吧。隨便改改湊合能用就好了！

這個是真的跟吃一樣難受

9月底剛入職新公司，之前那人留下的程式碼真的難看明白 各種奇怪的變數定義以及沒有註釋的方法看的頭疼。

最奇葩的還是有些功能介面還有幾個版本 比如xxxv1、xxxv2這種 頭都是大的 v2 又有呼叫v1的方法 刪又不能刪，怕遇到啥問題

頭疼

剛入行那會，奈何能力有限，施展渾身解數，寫了個特別長的業務方法，結合測試的時候老是通不過，後來身邊核心開發，組長，專案經理都在我旁邊看我除錯，當時內心慌得一匹，等他們看完程式碼邏輯後，得出一個結論：這麼寫，好像也沒什麼不對，就是太繞了。我想大概就是這種狀況吧

我入職三天了，專案之前全是畢業生寫的，聽說之前的都被開了，現在重構，沒註釋沒文件，不規範，程式碼髒亂差，我都想離職了

一個儲存過程幾千行。裡面巢狀合眾儲存過程和函式，n個臨時表，註釋少得可憐，沒有任何資料庫欄位說明，爽不爽（｀Δ´）！還有一個幾乎沒有任何註釋的cs程式碼，我一步一步除錯下來等到執行結束足足用了40多分鐘。