工作六七年以來，接手過無數個爛攤子，屎山雕花、開關編程已經成為常態。下面細數一下降低代碼可讀性，增加維護難度的12個編碼“技巧”。
假設一個叫“二狗”的程序員，喜歡做以下事情。
1. 二狗積極拆分微服務，一個表對應一個微服務
二狗十分認可微服務的設計思想。認為微服務可以獨立開發和發佈，每次改動不會影響其他系統。大大提高了開發人員的效率和線上穩定性。還可以在新服務裡使用新的技術，例如JDK 21。
於是狗哥把微服務的思想發揮到極致，每一張表都是一個服務。系統的應用架構圖十分壯觀。狗哥自豪地跟新同學講解自己設計的系統。新同學看著十幾個服務陷入了思考，不停地問著每個服務的作用，幹了什麼。狗哥很滿足。
新同學第一次開發需求，表現很差。雖然他要改10個服務，但是每個服務隻改動了一點點。並且由於服務之間都是Rpc調用，需要定義大量的接口，他需要發佈好多的 jar，定義版本號，解決測試環境版本沖突，測試和上線階段可把他忙壞了。
光是梳理上線順序，新同學就請教了狗哥三次。最後還是狗哥幫他上線了3 個服務，新同學才趕在凌晨 3 點前把所有的服務發完。看著新同學買了奶茶的份上，狗哥這次才沒有和領導吐槽，“這個同學不行啊，上個線都這麼費勁”。
微服務過多，也困擾著狗哥。雖然線上流量不高，但是由於“微服務太多，系統架構復雜”，接口性能不行。
於是狗哥開始進行重構，他重新加了一個開關，新邏輯可以減少Rpc，調用提高性能。狗哥在代碼中加了註釋“新邏輯”。
狗哥把代碼上線了，但是在線上環境不敢放開，隻在測試環境打開了開關。
2. 二狗積極重構代碼，但是線上不放量
狗哥喜歡對代碼進行重構，狗哥和領導吹牛，說“重構後的代碼性能更強，更穩定”。狗哥還添加了註釋“這是新邏輯”。
但是狗哥在線上比較謹慎，並沒有進行放量。隻是在測試環境，放開了全量。
新接手的同學不知道線上還沒放量，看到“這是新邏輯”，他就在狗哥的“新邏輯”上改代碼。測試環境驗證一切正常，到了線上階段卻怎麼也跑不通。
此時新同學才發現“新邏輯”的開關沒有打開，你猜，他敢打開這個開關嗎？於是他隻能刪代碼，在舊邏輯上重新開發。等到改完代碼，再上線時，已經天亮了。
由於這次上線問題，大傢一起熬夜加班，需求上線被推遲。新同學被產品和測試一頓騎臉輸出。新同學委屈得想要離職。
3. 二狗喜歡挑戰自我，方法長度一定要超過1000行
二狗寫代碼天馬行空。二狗認為提煉新方法會打斷自己的編碼思路，代碼越長，邏輯越連貫，可讀性越高。二狗還認為，優秀的程序員寫的方法都是非常長的。這能體現個人的能力。
二狗不光自己寫超長的方法，在改別人的代碼時，也從不提煉新的方法。二狗總是在原來的方法中添加更長的一段代碼。
新同學接手代碼時速度很慢，即使加班到凌晨，也不理解狗哥代碼設計的藝術。狗哥還向領導抱怨，“你最近招的人不行啊，一個小需求開發這麼久，上線還出了bug”。
4. 二狗喜歡挑戰自我，一個方法 if/try/else 要嵌套10層以上
二狗寫代碼十分認真，想到哪裡就寫哪裡。if/else/try catch 層層嵌套。狗哥的思路很快，並且思考全面。
嵌套十幾層的代碼一點bug都沒有，測試同學都誇贊狗哥“代碼質量真高啊，一個bug都沒有”。
新同學接手新代碼時，看到嵌套十幾層的代碼，大腦瞬間就要爆炸。想要罵人，但是看到代碼作者是狗哥……
無奈之下，自己實在看不懂這段代碼，於是點了一杯奶茶，走到了狗哥工位旁，“狗哥，多喝點水，給你點了一杯奶茶。…………這段代碼能給我講講嗎？”
狗哥過幾天和領導閑聊天，“新來的同學人不錯，還給我點奶茶喝”。
5. 二狗認為變量命名是藝術，要隨機命名，不要和業務邏輯有關系
二狗覺得寫代碼是藝術，就好像畫畫一樣。“你見過幾個人能看懂梵高的畫？” 狗哥曾經和旁邊人吹牛。
二狗寫代碼思路十分奇特，有時候來不及想變量如何命名，有時候是懶得想變量命名。狗哥經常隨便就命名了，例如 str1，str2，list1，list2等等。不得不說，狗哥的思維還是敏捷的，這麼多變量命名都能記住，還不出bug。
但是狗哥記性不大行，過一兩個月就不太記得這些變量的意義了。
6. 二狗積極寫註釋，但是寫了錯誤的註釋
一個成熟穩重的程序員改別人代碼時會十分慎重，如果有代碼註釋，他們一定會十分認真閱讀並嘗試理解它。
二狗喜歡把註釋引入錯誤的方向，例如 “是” 改成 “不是”，“更好”改成“更差”，把兩處不相幹的註釋交換一下位置 等。
新接手的同學點了一杯奶茶，虛心求助二狗，“狗哥，你寫的這段註釋有什麼深意啊，我看了三天，也不理解啊”。
到時候狗哥就可以給新同學一邊裝B，一邊講代碼了。當然還要看心情，要是不口渴，可以講講。
7. 二狗改代碼很認真，但是註釋從來不改
二狗改代碼真的非常認真，但是他不喜歡改註釋。最終代碼大改特改，註釋紋絲不動。最終代碼和註釋不相幹，部分正確，部分錯誤。
新接手的同學研究了兩天也沒搞明白，於是求助了狗哥。
到時候狗哥就可以大展神威了 。“那段註釋是錯的，你別管，就當沒有！”
狗哥順便還說了一句，“優秀的代碼不需要寫註釋，也不知道是哪個XX 寫的註釋”，成功收割新同學的“欽佩”之情。
8. 二狗喜歡復制代碼
狗哥寫代碼十分著急，根本來不及重構。他總是想到一段代碼，就復制過來。神奇的是，狗哥經常這麼寫，但是也沒出什麼問題。
但新同學就慘了，在改完狗哥的代碼後，總被測試同學背地裡吐槽，“一點小需求咋這麼多bug，跟狗哥比差遠了”。原來新同學改了一處，忘了改另外幾處，代碼被復制了好多遍，他實在無法全面梳理。
於是每次代碼寫完，新同學都要不停地研究代碼，總是害怕自己少改了哪些地方，下班時間越來越晚。並且新同學也不敢把雷同的代碼重構到一起。（你們猜猜他為什麼不敢？）
慢慢的，組裡的人都被迫向狗哥學習，狗哥成功輸出了自己的編碼習慣。
9. 二狗積極寫技術方案，但是最終代碼實現不按照技術方案來
二狗非常喜歡寫技術方案，大部分時間都花在技術方案上，總是把技術方案打磨得滑不留手。但是在寫代碼時，狗哥總覺得按照方案設計寫代碼，時間上根本來不及啊，還是簡單來吧，湊活實現吧。
例如狗哥曾經設計了一套復雜的Redis秒殺庫存系統，但是實現時選擇了最Low的數據庫同步扣減方案。
狗哥寫的流程圖和實際代碼也沒什麼關系。但是流程圖旁邊加滿了註釋和說明，讓人覺得“這個技術方案很權威”。
新同學熟悉項目時，從公司文檔中搜到了很多技術方案，本以為可以很快熟悉系統，但是發現技術方案和代碼不太一樣，越看越迷惑。
於是點了奶茶再次走向了狗哥，狗哥告訴他，“那個技術方案太復雜，排期緊張，開發來不及。你就當沒那個技術方案。”
10. 二狗十分自信，從不打日志
二狗對自己的代碼十分自信，認為不會出現任何問題，所以他從來不打日志。每次開發代碼時，狗哥的思維天馬行空，但是從來不想加個日志會有助於排查問題。
直到有一天，線上真的出問題了，除了異常堆棧，找不到其他有效的日志。大傢面面相覷，不知道怎麼辦。狗哥挺身而出，重新加了日志，上線。故障持續了不知道有多久，看著狗哥忙碌，領導不停地詢問還需要多久才能上線。
復盤會上，有人對狗哥不寫日志的行為進行批判，狗哥卻狡辯“加了日志，就能避免這次故障嗎？出問題還不是因為你們系統出了bug，跟我不打日志有啥關系。”雙方陷入了無限的扯皮之中……
11. 二狗積極學習，引用一個高大上的框架解決一個小問題
二狗非常喜歡學習，學習了很多高大上的框架。最近二狗學習了規則引擎，覺得這是個好東西，恰好最近在進行重構。於是二狗把 drools、avatior、SPEL等規則引擎、表達式求值等框架引入系統。隻是為了解決策略模式的問題。即何種條件下使用哪種策略。狗哥在系統架構圖裡，著重講了規則引擎部分，十分自豪。
新同學熟悉系統後，光是規則引擎部分就看了足足一周。但是還是不知道怎麼修改代碼。於是向狗哥請教。狗哥告訴他，“你在這個地方加一行代碼 rule.type == 12 ，走這個 CommonStrategy 策略類就可以了”。
新同學恍然大悟，原來這就是規則引擎啊。但是為什麼不用策略模式呢？好像策略模式不費事啊！狗哥技術就是強啊，殺雞用核彈。
12. 二狗積極造輪子，能造輪子的程序員才是牛掰的程序員
二狗非常喜歡造輪子，他對開源軟件的大神們心向往之，覺得自己應該向他們學習。狗哥認為造輪子才能更快地成長。
於是在狗哥的積極學習下，組裡的分佈式鎖沒有使用 redission，而是自己用setnx搞的。雖然後面出了問題，但是狗哥的技術得到了鍛煉。
總結
降低代碼可讀性的方式方法包括但不限於以上12種；
- 像二狗這樣的程序員包括但不限於二狗。
- 大傢不要向二狗學習，因為他是真的。
作者丨五陽神功
來源丨juejin.cn/post/7286155742850449471
dbaplus社群歡迎廣大技術人員投稿，投稿郵箱：[email protected]