熱搜: 老榕樹  聯盟  網站  cpa  廣告  阿里  榕樹  淘寶  產品  cps 
 
當前位置: 首頁 » 站長資訊 » 網站優化 » 正文

老司機教你如何寫出沒人敢維護的代碼!

放大字體  縮小字體 發布日期:2019-06-27  瀏覽次數:7
核心提示:本文來自于微信公眾號程序人生(ID:coder_life),作者:阿木,站長之家經授權轉載。編寫除了自己沒人能看懂的代碼,是一種怎樣的體驗?下面由作為資深挖坑程序員的我,手把手教大家這是怎么做到的?如果各位可以在接下

本文來自于微信公眾號程序人生(ID:coder_life),作者:阿木,站長之家經授權轉載。

編寫除了自己沒人能看懂的代碼,是一種怎樣的體驗?

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

編寫無法維護的代碼說難其實并不難,核心要點就是和編碼規范反其道而行之,如果在此基礎上再添加一些自己琢磨出的心得的話那就更加完美了。

掌握了這個要點還不夠,還要注意一個原則:不要讓我們的代碼一眼看上去就無法維護,格式之類的還是要注意些的,我們要追求的不是這種膚淺的表面上的無法維護,我們要的是實質是無法維護的。

要是別人一眼就能看出你的代碼無法維護,那你的代碼就存在需要重寫或者重構的風險了,那不成了前功盡棄親者痛,仇者快的事情了嘛。

了解清常規編程的思維方式再下手!

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

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

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

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

每一個我們精心設計的這些小陷阱都會迫使代碼維護者像用放大鏡似的,仔細地閱讀我們的每一行代碼。

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

第一招:一本正經地亂用注釋

這一部分我們先了解下注釋的正常用途:注釋是用來幫助開發者理解程序的,尤其是對于后來的開發者,通過注釋可以更快的了解代碼的實際作用。

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

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

在實際工作中,在對代碼進行修改后一定要連同代碼的注釋也一起進行修改。關于注釋的其他的一些作用我們在此不再多說,光是這些就已經足夠我們用的了。

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

一、多整沒用的

這塊我分了兩種情況來描述,兩種情況對應兩種處理方式,實用性比較強。

明顯型注釋

讓維護者浪費時間看顯而易見的注釋。

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

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

然后我們的注釋要寫的長一些,最后是要閱讀者看不懂,改的時候猶豫不決。

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

下面看個例子:

廢棄代碼注釋

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

針對性的做法就是給刪掉的代碼加個長長的注釋,寫明這段代碼為什么會被注釋起來,也向維護者傳達了一個信息,即這段代碼不是被”廢棄”的,而是”臨時”先不用。

這樣做的殺傷點就在,如果只注釋了代碼沒加注釋說明,根據實際經驗大家多數會直接略過被注釋的代碼,而給代碼加了注釋后看代碼的人可能就要看看這個注釋了,不然會漏掉什么關鍵信息,畢竟代碼不是他寫的。

樣板代碼:

二、這個地方將來會修改

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

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

樣板代碼:

三、錯誤注釋信息

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

我們要做的就是改完代碼后不改注釋就行了,此種方式比較省事,額外工作一點也不用多做,但是稍微有些代價,需要注意的是最好是在此類注釋中加個特殊的標記,防止自己后續看的時候把自己也繞進去。

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

四、講故事

簡單說來就是寫明這段代碼為什么要這樣寫,當然肯定不是單純的原因。除了原因一般建議在注釋中寫上當時的情況,比如某年某月和某人在某地討論了這個問題,某人說這個問題應該怎樣處理,你說這個問題不該這樣處理應該那樣處理,后來某某人又加入了討論,某某人對倆的討論做了某某的評價,最后決定要用現在的代碼去實現這塊的功能。

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

樣板代碼:

五、不要寫原因

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

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

六、瑣碎

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

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

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

七、單位問題

單位這部分和具體的業務場景相關,比如時間相關的一般會有毫秒、秒、分鐘、小時、天、月、年等,涉及尺寸的場景如像素、英寸等,涉及文件大小的場景如字節、KB、MB、GB等。

這一類的代碼中我們的原則是不對單位進行注釋,只管使用,如果可以在代碼中各種單位混用,那自然是更加優秀。

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

按照我們的正常邏輯,后面的人要想改這部分的代碼的邏輯首先要先弄懂各個數據的單位,搞清楚之前肯定是不敢隨意修改的,一般這種情況只有一種解決辦法那就是一遍遍的調試、測試程序來推算各個數據實際的單位,花費的時間自然是相當的多。

八、恐嚇

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

這樣維護人員在看到這段代碼的時候肯定首先會聯想到自己以前看過的一些文章,并堅信這段“廢話代碼”肯定是不能刪除的。代碼中如果存在多處這種注釋的話效果更佳。

 

 
 
[ 站長資訊搜索 ]  [ 加入收藏 ]  [ 告訴好友 ]  [ 打印本文 ]  [ 違規舉報 ]  [ 關閉窗口 ]

 
0條 [查看全部]  相關評論

 
推薦圖文
點擊排行
 
網站首頁 | 網站地圖 | 廣告服務 | 積分換禮 | 網站留言 | RSS訂閱 | 閩ICP備17002783號
評論內容只代表網友觀點,與搜聯盟-廣告聯盟點評網立場無關!請網友注意辨別評論內容。
Powered by SoLMw.com
 
美人鱼送彩金