工作六七年以來，接手過無數個爛攤子，屎山雕花、開關編程已經成為常態。下面細數一下 降低程式碼可讀性，增加維護難度 的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]
