降低代碼可讀性，增加維護難度的12個編碼“技巧”

下面細數一下 降低代碼可讀性，增加維護難度的 12 個編碼“技巧”。

假設一個叫”二狗“ 的程序員，喜歡做以下事情。

1 二狗積極拆分微服務，一個表對應一個微服務

二狗十分認可微服務的設計思想。認為微服務可以獨立開發和發布，每次改動不會影響其他系統。大大提高了開發人員的效率和線上穩定性。還可以在新服務里使用新的技術，例如JDK 21

于是狗哥把微服務的思想發揮到極致，每一張表都是一個服務。系統的應用架構圖十分壯觀。狗哥自豪的跟新同學講解自己設計的系統。新同學看著十幾個服務陷入了思考，不停地問著每個服務的作用，干了什么。狗哥很滿足。

新同學第一次開發需求，表現很差。雖然他要改10個服務，但是每個服務只改動了一點點。并且由于服務之間都是Rpc調用，需要定義大量的接口，他需要發布好多的 jar，定義版本號，解決測試環境版本沖突，測試和上線階段可把他忙壞了。

光是梳理上線順序，新同學就請教了狗哥 三次。最后還是狗哥幫他上線了3 個服務，新同學才趕在 凌晨 3 點前把所有的服務發完?？粗峦瑢W買了奶茶的份上，狗哥這次才沒有和領導吐槽，“這個同學不行啊，上個線都這么費勁”

微服務過多，也困擾著狗哥。雖然線上流量不高，但是由于 “微服務太多，系統架構復雜"，接口性能不行。

于是狗哥開始進行重構，他重新加了一個開關，新邏輯可以減少Rpc，調用提高性能。狗哥在代碼中加了注釋 "新邏輯"。

狗哥把代碼上線了，但是在線上環境不敢放開，只在測試環境打開了開關。

2 二狗積極重構代碼，但是線上不放量

狗哥喜歡對代碼進行重構，狗哥和領導吹牛，說“ 重構后的代碼性能更強，更穩定”。狗哥還添加了注釋 ”這是新邏輯 “。

但是狗哥在線上比較謹慎，并沒有進行放量。只是在測試環境，放開了全量。

新接手的同學不知道線上還沒放量，看到“這是新邏輯” ，他就在狗哥的“新邏輯”上改代碼。測試環境驗證一切正常，到了線上階段卻怎么也跑不通。

此時新同學才發現 ”新邏輯“ 的開關沒有打開，你猜，他敢打開這個開關嗎？于是他只能刪代碼，在舊邏輯上重新開發。等到改完代碼，再上線時，已經天亮了。

由于這次上線問題，大家一起熬夜加班，需求上線被推遲。新同學被產品和測試一頓騎臉輸出。新同學委屈的想要離職。

3 二狗喜歡挑戰自我，方法長度一定要超過1000行

二狗寫代碼天馬行空。二狗認為提煉新方法會打斷自己的編碼思路，代碼越長，邏輯越連貫，可讀性越高。二狗還認為 優秀的程序員寫的方法都是 非常長的。這能體現個人的能力。

二狗不光自己寫超長的方法，在改別人的代碼時，也從不提煉新的方法。二狗總是在原來的方法中添加更長的一段代碼。

新同學接手代碼時速度很慢，即使加班到凌晨，也不理解狗哥代碼設計的藝術。狗哥還向領導抱怨，”你最近招的人不行啊，一個小需求開發這么久，上線還出了bug?！?/p>

4 二狗喜歡挑戰自我，一個方法 if/try/else 要嵌套10層以上

二狗寫代碼十分認真，想到哪里就寫哪里。if/else/try catch 層層嵌套。狗哥的思路很快，并且思考全面， 嵌套十幾層的代碼一點bug都沒有，測試同學都夸贊狗哥 ”代碼質量真高啊 “，一個bug都沒有。

新同學接手新代碼時，看到嵌套十幾層的代碼，大腦瞬間就要爆炸。想要罵人，但是看到代碼作者是狗哥……

無奈之下，自己實在看不懂這段代碼，于是點了一杯奶茶，走到了狗哥工位旁，”狗哥，多喝點水，給你點了一杯奶茶?！@段代碼能給我講講嗎？“

狗哥過幾天和領導閑聊天，“新來的同學人不錯，還給我點奶茶喝”

5 二狗認為變量命名是藝術，要隨機命名，不要和業務邏輯有關系

二狗覺得寫代碼是藝術，就好像畫畫一樣?！蹦阋娺^幾個人能看懂 梵高的畫？” 狗哥曾經和旁邊人吹牛。

二狗寫代碼思路十分奇特，有時候來不及想變量如何命名，有時候是懶得想變量命名。狗哥經常隨便就命名了，例如 str1，str2，list1，list2等等。不得不說，狗哥的思維還是敏捷的，這么多變量命名都能記住，還不出bug。

但是狗哥記性不大行，過一兩個月就不太記得這些變量的意義了。

6 二狗積極寫注釋，但是寫了錯誤的注釋

一個成熟穩重的程序員改別人代碼時會十分慎重，如果有代碼注釋，他們一定會十分認真閱讀并嘗試理解它。

二狗喜歡把注釋引入錯誤的方向，例如 “是” 改成 “不是”，“更好”改成”更差“，把兩處不相干的注釋交換一下位置 等。

新接手的同學點了一杯奶茶，虛心求助二狗，“狗哥，你寫的這段注釋有什么深意啊，我看了三天，也不理解啊”。

到時候狗哥就可以給新同學一邊裝B，一邊講代碼了。當然還要看心情，要是不口渴，可以講講。

7 二狗改代碼很認真，但是注釋從來不改

二狗改代碼真的非常認真，但是他不喜歡改注釋。最終代碼大改特改，注釋紋絲不動。最終代碼和注釋不相干，部分正確，部分錯誤。

新接手的同學研究了兩天也沒搞明白。于是求助了狗哥

到時候狗哥就可以大展神威了 ?！蹦嵌巫⑨屖清e的，你別管，就當沒有！“

狗哥順便還說了一句，”優秀的代碼不需要寫注釋，也不知道是哪個XX 寫的注釋“，成功收割新同學的＂欽佩＂之情。

8 二狗喜歡復制代碼

狗哥寫代碼十分著急，根本來不及重構。他總是想到一段代碼，就復制過來。神奇的是，狗哥經常這么寫，但是也沒出什么問題。

但新同學就慘了，在改完狗哥的代碼后，總被測試同學背地里吐槽，“一點小需求咋這么多bug，跟狗哥比差遠了”。原來新同學改了一處，忘了改另外幾處，代碼被復制了好多遍，他實在無法全面梳理。

于是每次代碼寫完，新同學都要不停的研究代碼，總是害怕自己少改了哪些地方，下班時間越來越晚。并且新同學也不敢把雷同的代碼重構到一起。（“你們猜猜他為什么不敢？）

慢慢的，組里的人都被迫向狗哥學習，狗哥成功輸出了自己的編碼習慣。

9 二狗積極寫技術方案，但是最終代碼實現不按照技術方案來

二狗非常喜歡寫技術方案，大部分時間都花在技術方案上，總是把技術方案打磨的 滑不留手。但是在寫代碼時，狗哥總覺得按照方案設計寫代碼，時間上根本來不及啊，還是簡單來吧，湊活實現吧。

例如狗哥曾經設計了一套復雜的Redis秒殺庫存系統，但是實現時選擇了最Low的 數據庫同步扣減方案。

狗哥寫的流程圖和實際代碼也沒什么關系。但是流程圖旁邊加滿了注釋和說明，讓人覺得 ”這個技術方案很權威“。

新同學熟悉項目時，從公司文檔中搜到了很多技術方案，本以為可以很快熟悉系統，但是發現技術方案和代碼不太一樣。越看越迷惑。

于是點了奶茶再次走向了狗哥，狗哥告訴他，“那個技術方案太復雜，排期緊張，開發來不及。你就當沒那個技術方案?！?/p>

10 二狗十分自信，從不打日志。

二狗對自己的代碼十分自信，認為不會出現任何問題，所以他從來不打日志。每次開發代碼時，狗哥的思維天馬行空，但是從來不想加個日志會有助于排查問題。

直到有一天，線上真的出問題了，除了異常堆棧，找不到其他有效的日志。大家面面相覷，不知道怎么辦。狗哥挺身而出，重新加了日志，上線。故障持續了不知道有多久……，看著狗哥忙碌，領導不停地詢問還需要多久才能上線。

復盤會上，有人對狗哥不寫日志的行為進行批判，狗哥卻在 狡辯 “加了日志，就能避免這次故障嗎？出問題還不是因為你們系統出了bug，跟我不打日志有啥關系?！?雙方陷入了無限的扯皮之中……

11 二狗積極學習，引用一個高大上的框架 解決一個小問題

二狗非常喜歡學習，學習了很多高大上的框架。最近二狗學習了規則引擎，覺得這是個好東西，恰好最近在進行重構。于是二狗把 drools、avatior、SPEL等規則引擎、表達式求值 等框架引入系統。只是為了解決策略模式的問題。即何種條件下使用哪種策略。狗哥在系統架構圖里，著重講了規則引擎部分，十分自豪。

新同學熟悉系統后，光是規則引擎部分就看了足足一周。但是還是不知道怎么修改代碼。于是向狗哥請教。狗哥告訴他說，" 你在這個地方 加一行代碼 rule.type == 12 ，走這個 CommonStrategy 策略類就可以了?！?/p>

新同學恍然大悟，原來這就是規則引擎啊。但是為什么不用策略模式呢？好像策略模式不費事??！狗哥技術就是強啊，殺雞用核彈。

12 二狗積極造輪子，能造輪子的程序員才是牛掰的程序員

二狗非常喜歡造輪子，他對開源軟件的大神們心向往之，覺得自己應該向他們學習。狗哥認為 造輪子才能更快地成長。

于是在狗哥的積極學習下，組里的 分布式鎖 沒有使用 redission，而是自己用setnx搞的。雖然后面出了問題，但是狗哥的技術得到了鍛煉。

總結

降低代碼可讀性的方式方法 包括但不限于以上12種；

像二狗這樣的程序員包括但不限于二狗。

審核編輯：劉清