教你如何寫出沒人敢維護(hù)的代碼_中博培訓(xùn)學(xué)校

　編寫除了自己沒人能看懂的代碼，是一種怎樣的體驗(yàn)?

下面由作為資深挖坑程序員的我，手把手教大家這是怎么做到的?如果各位可以在接下來的時(shí)間多加練習(xí)，所謂青出于藍(lán)勝于藍(lán)，相信各位不但可以寫出別人無法維護(hù)的代碼，還可能在有朝一日，甚至能技藝爐火純青地寫出自己都維護(hù)不了的代碼。

編寫無法維護(hù)的代碼說難其實(shí)并不難，核心要點(diǎn)就是和編碼規(guī)范反其道而行之，如果在此基礎(chǔ)上再添加一些自己琢磨出的心得的話那就更加完美了。

掌握了這個(gè)要點(diǎn)還不夠，還要注意一個(gè)原則：不要讓我們的代碼一眼看上去就無法維護(hù)，格式之類的還是要注意些的，我們要追求的不是這種膚淺的表面上的無法維護(hù)，我們要的是實(shí)質(zhì)是無法維護(hù)的。

要是別人一眼就能看出你的代碼無法維護(hù)，那你的代碼就存在需要重寫或者重構(gòu)的風(fēng)險(xiǎn)了，那不成了前功盡棄親者痛，仇者快的事情了嘛。

了解清常規(guī)編程的思維方式再下手

《孫子兵法》有云“知己知彼，百戰(zhàn)不殆”，假如我們要想從心理上徹底擊敗后續(xù)的代碼維護(hù)人員，我們必須明白常規(guī)編程中的一些思維方式。

各位先想下，如果接手程序的是我們自己，而且代碼量比較大，一般我們是沒有時(shí)間去從頭到尾一行一行地讀一遍的，更不要說能理解代碼了。

為了能盡快地上線交差，程序員常見的做法是根據(jù)需求，先快速找到代碼中需要改動(dòng)的那一部分邏輯，然后對(duì)這部分的代碼進(jìn)行修改、測試。這種修改方式一次只能看到代碼的一小部分，管中窺豹。

所以我們要做的是確保讓代碼維護(hù)人員永遠(yuǎn)看不到我們寫的代碼的全貌，要盡量保證代碼維護(hù)人員找不到他想要找到的那部分代碼。這還不是關(guān)鍵的，關(guān)鍵的是要讓修改者知道自己沒有忽略任何的東西。

每一個(gè)我們精心設(shè)計(jì)的這些小陷阱都會(huì)迫使代碼維護(hù)者像用放大鏡似的，仔細(xì)地閱讀我們的每一行代碼。

有些同學(xué)可能覺得這很簡單，認(rèn)為只要按照上文中提到的反編程規(guī)范原則來進(jìn)行即可。但是實(shí)際操作起來并沒有這么簡單，還需要配合我們的精心誤用才可。下面我們就對(duì)常用的一些核心技能娓娓道來。

第一招：一本正經(jīng)地亂用注釋

這一部分我們先了解下注釋的正常用途：注釋是用來幫助開發(fā)者理解程序的，尤其是對(duì)于后來的開發(fā)者，通過注釋可以更快的了解代碼的實(shí)際作用。

正常情況下代碼注釋的原則一般是只在需要注釋的地方進(jìn)行注釋。這是一句很正確的廢話，解釋起來就是很明顯就能看懂的代碼就不要去注釋的了，畢竟看注釋也是需要花費(fèi)時(shí)間的。

另外一個(gè)原則就是在注釋中注明代碼的作用需要和代碼的實(shí)際作用是一致。

在實(shí)際工作中，在對(duì)代碼進(jìn)行修改后一定要連同代碼的注釋也一起進(jìn)行修改。關(guān)于注釋的其他的一些作用我們?cè)诖瞬辉俣嗾f，光是這些就已經(jīng)足夠我們用的了。

如何利用代碼注釋寫出讓人無法理解的代碼呢?

一、多整沒用的

這塊我分了兩種情況來描述，兩種情況對(duì)應(yīng)兩種處理方式，實(shí)用性比較強(qiáng)。

明顯型注釋

讓維護(hù)者浪費(fèi)時(shí)間看顯而易見的注釋。

這部分的原則是維護(hù)者看完注釋后覺得“代碼比注釋容易讀多了”，目的就是誤導(dǎo)讀代碼的人。維護(hù)者在看代碼時(shí)，上眼一看代碼很清晰，但又一看竟然還有注釋。

此時(shí)讀代碼的人心里肯定是要嘀咕下：看來這代碼沒我想的這么簡單。

然后我們的注釋要寫的長一些，后是要閱讀者看不懂，改的時(shí)候猶豫不決。

如果有余力的話可以在注釋中教維護(hù)者怎么編程，這種一般殺傷力要比上面寫的會(huì)高一些，程序員反感的可能就是你要教他怎么編程了，尤其是教他這么簡單的編程，殺傷力加倍。

廢棄代碼注釋

字面意思已經(jīng)很清楚了，正常情況下代碼中不用的部分我們一般會(huì)注釋掉或者直接刪除掉，即使這段代碼將來會(huì)使用到也不影響，可以從版本控制工具中再找回來。

針對(duì)性的做法就是給刪掉的代碼加個(gè)長長的注釋，寫明這段代碼為什么會(huì)被注釋起來，也向維護(hù)者傳達(dá)了一個(gè)信息，即這段代碼不是被”廢棄”的，而是”臨時(shí)”先不用。

這樣做的殺傷點(diǎn)就在，如果只注釋了代碼沒加注釋說明，根據(jù)實(shí)際經(jīng)驗(yàn)大家多數(shù)會(huì)直接略過被注釋的代碼，而給代碼加了注釋后看代碼的人可能就要看看這個(gè)注釋了，不然會(huì)漏掉什么關(guān)鍵信息，畢竟代碼不是他寫的。

二、這個(gè)地方將來會(huì)修改

　　這種注釋就是我們經(jīng)常提到的“TODO”型注釋。正常情況下TODO注釋并非一無是處，比如在初始化項(xiàng)目的時(shí)候TODO注釋還是非常有用的，到項(xiàng)目release 時(shí)一般是建議去掉的，如果必須要留著一般需要寫明在具體什么日期會(huì)處理掉。一般是不推薦TODO型注釋長期存在于項(xiàng)目的代碼中，正常的處理邏輯一般是遵循有Bug盡快Fix，無Bug則去掉注釋。

　　通過上面的描述相信大家已經(jīng)知道這塊具體要怎么應(yīng)對(duì)了。個(gè)人建議是對(duì)于有待修改的多寫點(diǎn)TODO注釋，且不注明更改的原因以及計(jì)劃更改的時(shí)間，這樣后面的維護(hù)人員在看的時(shí)候可能連這塊到底是不是已經(jīng)改過了都搞不清楚，所以殺傷效果也是有一些的。

三、錯(cuò)誤注釋信息

　　這部分的意思是造成代碼和注釋的不匹配，也就是注釋的信息不正確。

　　我們要做的就是改完代碼后不改注釋就行了，此種方式比較省事，額外工作一點(diǎn)也不用多做，但是稍微有些代價(jià)，需要注意的是好是在此類注釋中加個(gè)特殊的標(biāo)記，防止自己后續(xù)看的時(shí)候把自己也繞進(jìn)去。

　　樣板實(shí)例這塊就不用加了吧，場景太多了，大家在自己的一畝三分地上耕作時(shí)臨場發(fā)揮即可。

四、講故事

　　簡單說來就是寫明這段代碼為什么要這樣寫，當(dāng)然肯定不是單純的原因。除了原因一般建議在注釋中寫上當(dāng)時(shí)的情況，比如某年某月和某人在某地討論了這個(gè)問題，某人說這個(gè)問題應(yīng)該怎樣處理，你說這個(gè)問題不該這樣處理應(yīng)該那樣處理，后來某某人又加入了討論，某某人對(duì)倆的討論做了某某的評(píng)價(jià)，后決定要用現(xiàn)在的代碼去實(shí)現(xiàn)這塊的功能。

　　總之，原則就是把事情的細(xì)節(jié)描述清楚，越細(xì)越好。有些同學(xué)可能會(huì)建議將當(dāng)天的天氣情況也寫上，還有討論中那個(gè)氣死人的S*名字也要帶上，我個(gè)人認(rèn)為天氣可以酌情添加，但寫上S*名字是不太鼓勵(lì)的，畢竟同事一場，要相互愛護(hù)的，大家按照自己公司的實(shí)際情況來選擇具體的處理方式吧。

五、不要寫原因

　　按照注釋的規(guī)范，注釋時(shí)不但要解釋程序的表述的意思，更重要的是寫明為什么寫，即代碼這么寫的原因是什么。

　　這樣應(yīng)對(duì)之策也已經(jīng)顯而易見了，對(duì)于復(fù)雜程序，比如一些特殊的邊界條件判斷，只寫下程序的字面意思，具體邊界值判斷為什么要這樣寫，為什么是這個(gè)值可以忽略掉，讓維護(hù)的人盡情去猜吧。

六、瑣碎

　　在這需要注明的是大部分程序注釋一般是用不到這種情況的，一般是推薦放在一些復(fù)雜算法的解釋上，越是復(fù)雜的算法越是推薦，原則就是把這部分應(yīng)該寫到文檔中的內(nèi)容寫到代碼中。

　　一定要把算法的所有的詳細(xì)設(shè)計(jì)都寫上，注釋內(nèi)容分段落，段落之間要分級(jí)，每個(gè)段落建議加上編號(hào)，這樣就基本可以保證代碼的注釋和文檔的內(nèi)容保持一致。后續(xù)的維護(hù)看到這樣的注釋的時(shí)候基本可以保證頭大一圈，如果此類注釋存在多處的話效果更佳。

　　鑒于樣板示例中注釋篇幅太長就不加示例了。

七、單位問題

　　單位這部分和具體的業(yè)務(wù)場景相關(guān)，比如時(shí)間相關(guān)的一般會(huì)有毫秒、秒、分鐘、小時(shí)、天、月、年等，涉及尺寸的場景如像素、英寸等，涉及文件大小的場景如字節(jié)、KB、MB、GB等。

　　這一類的代碼中我們的原則是不對(duì)單位進(jìn)行注釋，只管使用，如果可以在代碼中各種單位混用，那自然是更加優(yōu)秀。

　　比如在關(guān)于文件處理的場景中，KB、MB、GB多個(gè)單位混合使用，這樣后來的維護(hù)人員要想搞懂這部分代碼中單位的真正含義就要下一番功夫了。

　　按照我們的正常邏輯，后面的人要想改這部分的代碼的邏輯首先要先弄懂各個(gè)數(shù)據(jù)的單位，搞清楚之前肯定是不敢隨意修改的，一般這種情況只有一種解決辦法那就是一遍遍的調(diào)試、測試程序來推算各個(gè)數(shù)據(jù)實(shí)際的單位，花費(fèi)的時(shí)間自然是相當(dāng)?shù)亩唷?/p>

八、恐嚇

　　這一招可以說是殺手锏級(jí)別的注釋，可以在程序中加一部分可有可無的代碼，而且是很明顯可有可無的那種，然后給這段程序加個(gè)注釋，注釋中寫明“千萬不要注釋掉或者刪除這段代碼，否則程序會(huì)出現(xiàn)異常!!!”，需要注意的是不要解釋會(huì)出現(xiàn)什么樣的異常。

　　這樣維護(hù)人員在看到這段代碼的時(shí)候肯定首先會(huì)聯(lián)想到自己以前看過的一些文章，并堅(jiān)信這段“廢話代碼”肯定是不能刪除的。代碼中如果存在多處這種注釋的話效果更佳。

障眼法篇

一、入門

　　讓你的代碼和注釋交融在一起，算是入門級(jí)的代碼偽裝術(shù)，主要目的是惡心后來的維護(hù)者，假使看代碼的人剛好頭昏腦漲的話肯定會(huì)直接懵逼一會(huì)，懵逼完之后再一陣惡心。

二、同義詞

　　這種招式一般是建議用在C類程序的宏定義中，使用的原則也比較簡單，即宏名稱和具體的值雜糅使用即可，造成一種你中有我，我中有你的既視感。

三、命名不一致

　　這部分主要應(yīng)用在前端開發(fā)中，舉個(gè)例子大家就清楚了，比如Web界面上郵政編碼顯示為postal code，代碼中把變量名命名為zipcode，我相信不論誰看到這種情況都不敢直接改代碼的，肯定要反復(fù)確認(rèn)一會(huì)postal code 對(duì)應(yīng)的變量到底是不是zipcode。

四、宏定義隱藏

　　需要說明的是這里的隱藏不是說將宏定義藏到找不到的地方，那肯定是不行的，說不定我們自己還要進(jìn)行修改呢。

　　這里說的宏定義隱藏是指將宏定義寫的不像宏定義，讓看代碼的人一眼看去覺得這不是一個(gè)宏，然后略過去。

五、變量名換行

　　這一招我只能用猥瑣來形容了，因?yàn)檎娴氖氢崱．a(chǎn)生的效果是即難閱讀也很難進(jìn)行變量名的搜索。

六、全局變量

　　這里說的是隱藏全局變量，方法就是在函數(shù)里面使用全局變量時(shí)不直接使用，而是以傳參的形式傳進(jìn)來后進(jìn)行使用，這樣很難分辨出這是一個(gè)全局變量。

七、函數(shù)重載

　　正常重載后的函數(shù)，其功能應(yīng)該和被重載的函數(shù)應(yīng)該是接近的，我們要做的就是讓重載后的函數(shù)和被重載函數(shù)的功能完全沒有關(guān)系。

　　這個(gè)時(shí)候看代碼的人如果基礎(chǔ)不牢的話，可能需要去溫習(xí)下函數(shù)重載的知識(shí)，是不是自己以前理解錯(cuò)了。

八、操作符重載

　　操作符重載是一種很變態(tài)的招式，因?yàn)樗麜?huì)讓你的代碼變的非常的詭異，只要按照下面描述的方式進(jìn)行使用基本可以把代碼的混亂程度直接拉升到藝術(shù)的級(jí)別，藝術(shù)就是打破常規(guī)，所以一般只要不按照操作符重載推薦的使用方式去使用都能收到意想不到的效果。

　　樣板示例：類中重載 ! 操作符，重載后的功能不是取反而讓其返回一個(gè)整數(shù)，于是當(dāng)使用!!時(shí)會(huì)先調(diào)用被重載后的函數(shù)，返回一個(gè)整數(shù)，然后再取反，后返回個(gè)bool值，一臉懵逼。

九、混亂

　　這一招用上后我覺得看代碼的人如果不是穩(wěn)如老狗的老司機(jī)應(yīng)該會(huì)抱頭痛哭的。

變量命令篇

一、大小寫任意交替

　　這種基本上就是一種罵娘的命名方式，為啥會(huì)這么容易引起怒火，看個(gè)例子就知道了：gGEtpRoDucTnaME，有沒有腦裂的感覺?

二、單字母變量

　　名稱上毫無邏輯可言。

三、字母+數(shù)字很配

　　如果字母a – z 不夠使用，可以考慮字母+數(shù)字的組合，這樣一般就足夠使用了，畢竟數(shù)字是無限的。

四、故意拼錯(cuò)

　　變量名稱拼錯(cuò)并不是隨意一個(gè)單詞就拼錯(cuò)，此處指的是比較有創(chuàng)意的拼寫錯(cuò)誤。

　　因?yàn)殡S意的拼寫錯(cuò)誤是很容易被發(fā)現(xiàn)的，高級(jí)的拼寫錯(cuò)誤由于很難看出來，所以在進(jìn)行變量搜索的時(shí)候根本搜不出來。 比如：SetPintle、SetPintalClosing。

五、重復(fù)名稱

　　函數(shù)或者方法的內(nèi)嵌結(jié)構(gòu)中使用和函數(shù)或者方法層面中同名的變量名，變量名多的話可能會(huì)一陣眩暈。

進(jìn)階篇

　　前面的注釋和變量命名可以說是本文的基礎(chǔ)篇，主要是較大家一些基本的編程技巧。這一篇作為進(jìn)階的一篇，我會(huì)給大家介紹一下常見的一些稍微高端的編程技巧，廢話不多說，一起看下：

一、void*

　　不管什么類型的指針一律都用聲明定義為void*，當(dāng)實(shí)際用到時(shí)再轉(zhuǎn)換為需要的類型。

二、條件表達(dá)式

　　條件表達(dá)式這塊可以發(fā)揮的空間就比較大了，從實(shí)際編碼情況來看，每個(gè)簡單的條件表達(dá)式都可以進(jìn)行拆分，看個(gè)例子就明白了。

　　10 == num，拆分為 num >= 99 && num <= 101

三、長代碼

　　什么，一行多80個(gè)字符? 不行，這才哪到哪，一定要跨行，而且要跨多行，不能因?yàn)閾Q行影響了我們寫代碼的那股激情。

　　原則就是越長越好，這樣后續(xù)閱讀代碼的人就需要來來回回地讀，想想都覺得累。

四、嵌套

　　一個(gè)優(yōu)秀的程序員必須能夠在一行代碼中使用超過10個(gè)小括號(hào)()，如果覺得很難得話在一個(gè)函數(shù)里面使用超過5層的大括號(hào)也是可以的，還不行的話把嵌套的條件語句if … else 轉(zhuǎn)為[?:] 也是可以說明你是個(gè)優(yōu)秀的程序員的。

五、不要break

　　不要在代碼的循環(huán)中使用break，更不要使用goto，這樣可以保證一行break可以處理的代碼少要寫5層的if … else 來解決，一遇到break 就多出百十行代碼，想想都過癮，一天下來光看看新增的代碼行數(shù)就覺得充實(shí)。

六、盡量使用XML

　　XML 的強(qiáng)大是無人能及的，不是JSON、Yaml這些所能及的。項(xiàng)目中使用XML 可以幫助我們將原來只需要10行的代碼變?yōu)?00行(可能還不止)。XML是無所不能的，哪怕是自己封裝自己也是可以做到的，信XML 得永生，信XML 的自信!

七、測試

　　測試，不存在的。

　　一般建議不要測試，測試是一種懦夫的行為，作為一個(gè)優(yōu)秀的程序員我們必須保持這種對(duì)自己代碼的自信，再者測試會(huì)影響你的生產(chǎn)力，直接影響你寫代碼的行數(shù)，所以測試這一步直接跳過就好啦。