如何編寫(xiě)無(wú)法維護(hù)的代碼

讓自己穩(wěn)拿鐵飯碗 ;-)

Roedy Green

簡(jiǎn)介

?

永遠(yuǎn)不要（把自己遇到的問(wèn)題）歸因于（他人的）惡意，這恰恰說(shuō)明了（你自己的）無(wú)能。-- 拿破侖

?

為了造福大眾，在Java編程領(lǐng)域創(chuàng)造就業(yè)機(jī)會(huì)，兄弟我在此傳授大師們的秘籍。這些大師寫(xiě)的代碼極其難以維護(hù)，后繼者就是想對(duì)它做最簡(jiǎn)單的修改都需要花上數(shù)年時(shí)間。而且，如果你能對(duì)照秘籍潛心修煉，你甚至可以給自己弄個(gè)鐵飯碗，因?yàn)槌四阒?#xff0c;沒(méi)人能維護(hù)你寫(xiě)的代碼。再而且，如果你能練就秘籍中的?全部?招式，那么連你自己都無(wú)法維護(hù)你的代碼了！

你不想練功過(guò)度走火入魔吧。那就不要讓你的代碼?一眼看去?就完全無(wú)法維護(hù)，只要它?實(shí)質(zhì)上是?那樣就行了。否則，你的代碼就有被重寫(xiě)或重構(gòu)的風(fēng)險(xiǎn)！

總體原則

?

Quidquid latine dictum sit, altum sonatur.(隨便用拉丁文寫(xiě)點(diǎn)啥都會(huì)顯得高大上。)

?

想挫敗維護(hù)代碼的程序員，你必須先明白他的思維方式。他接手了你的龐大程序，沒(méi)有時(shí)間把它全部讀一遍，更別說(shuō)理解它了。他無(wú)非是想快速找到修改代碼的位置、改代碼、編譯，然后就能交差，并希望他的修改不會(huì)出現(xiàn)意外的副作用。

他查看你的代碼不過(guò)是管中窺豹，一次只能看到一小段而已。你要確保他永遠(yuǎn)看不到全貌。要盡量和讓他難以找到他想找的代碼。但更重要的是，要讓他不能有把握?忽略?任何東西。

程序員都被編程慣例洗腦了，還為此自鳴得意。每一次你處心積慮地違背編程慣例，都會(huì)迫使他必須用放大鏡去仔細(xì)閱讀你的每一行代碼。

你可能會(huì)覺(jué)得每個(gè)語(yǔ)言特性都可以用來(lái)讓代碼難以維護(hù)，其實(shí)不然。你必須精心地誤用它們才行。

命名

?

"當(dāng)我使用一個(gè)單詞的時(shí)候" Humpty Dumpty 曾經(jīng)用一種輕蔑的口氣說(shuō), "它就是我想表達(dá)的意思，不多也不少?！? Lewis Carroll -- 《愛(ài)麗絲魔鏡之旅》， 第6章

?

編寫(xiě)無(wú)法維護(hù)代碼的技巧的重中之重是變量和方法命名的藝術(shù)。如何命名是和編譯器無(wú)關(guān)的。這就讓你有巨大的自由度去利用它們迷惑維護(hù)代碼的程序員。

妙用?寶寶起名大全

買(mǎi)本寶寶起名大全，你就永遠(yuǎn)不缺變量名了。比如??Fred?就是個(gè)好名字，而且鍵盤(pán)輸入它也省事。如果你就想找一些容易輸入的變量名，可以試試??adsf

或者?

aoeu

之類(lèi)。

單字母變量名

如果你給變量起名為a,b,c，用簡(jiǎn)單的文本編輯器就沒(méi)法搜索它們的引用。而且，沒(méi)人能猜到它們的含義。

創(chuàng)造性的拼寫(xiě)錯(cuò)誤

如果你必須使用描述性的變量和函數(shù)名，那就把它們都拼錯(cuò)。還可以把某些函數(shù)和變量名拼錯(cuò)，再把其他的拼對(duì)(例如 SetPintleOpening 和 SetPintalClosing) ，我們就能有效地將grep或IDE搜索技術(shù)玩弄于股掌之上。這招超級(jí)管用。還可以混淆不同語(yǔ)言（比如colour?-- 英國(guó)英語(yǔ)，和?color?

-- 美國(guó)英語(yǔ))。

抽象

在命名函數(shù)和變量的時(shí)候，充分利用抽象單詞，例如?it,?everything,?data,?handle,?stuff,?do,?routine,?perform?和數(shù)字，例如 e.g.??routineX48?,?PerformDataFunction?,??DoIt?,??HandleStuff

還有?

do_args_method

。

首字母大寫(xiě)的縮寫(xiě)

用首字母大寫(xiě)縮寫(xiě)（比如GNU 代表 GNU's Not Unix) 使代碼簡(jiǎn)潔難懂。真正的漢子(無(wú)論男女)從來(lái)不說(shuō)明這種縮寫(xiě)的含義，他們生下來(lái)就懂。

辭典大輪換

為了打破沉悶的編程氣氛，你可以用一本辭典來(lái)查找盡量多的同義詞。例如?display,?show,?present。在注釋里含糊其辭地暗示這些命名之間有細(xì)微的差別，其實(shí)根本沒(méi)有。不過(guò)，如果有兩個(gè)命名相似的函數(shù)真的有重大差別，那倒是一定要確保它們用相同的單詞來(lái)命名(例如，對(duì)于 "寫(xiě)入文件", "在紙上書(shū)寫(xiě)" 和 "屏幕顯示" 都用?print?

來(lái)命名)。 在任何情況下都不要屈服于編寫(xiě)明確的項(xiàng)目詞匯表這種無(wú)理要求。你可以辯解說(shuō)，這種要求是一種不專(zhuān)業(yè)的行為，它違反了結(jié)構(gòu)化設(shè)計(jì)的信息隱藏原則。

首字母大寫(xiě)

隨機(jī)地把單詞中間某個(gè)音節(jié)的首字母大寫(xiě)。例如?

ComputeReSult()

。

重用命名

在語(yǔ)言規(guī)則允許的地方，盡量把類(lèi)、構(gòu)造器、方法、成員變量、參數(shù)和局部變量都命名成一樣。更高級(jí)的技巧是在{}塊中重用局部變量。這樣做的目的是迫使維護(hù)代碼的程序員認(rèn)真檢查每個(gè)示例的范圍。特別是在Java代碼中，可以把普通方法偽裝成構(gòu)造器。

使用非英語(yǔ)字母

在命名中偷偷使用不易察覺(jué)的非英語(yǔ)字母，例如

typedef struct { int i; } ínt;

看上去沒(méi)啥不對(duì)是吧？嘿嘿嘿...這里的第二個(gè) ínt 的??í

實(shí)際上是東北歐字母，并不是英語(yǔ)中的 i 。在簡(jiǎn)單的文本編輯器里，想看出這一點(diǎn)點(diǎn)區(qū)別幾乎是不可能的。

巧妙利用編譯器對(duì)于命名長(zhǎng)度的限制

如果編譯器只區(qū)分命名的前幾位，比如前8位，那么就把后面的字母寫(xiě)得不一樣。比如，其實(shí)是同一個(gè)變量，有時(shí)候?qū)懗?var_unit_update()?，有時(shí)候又寫(xiě)成?var_unit_setup()，看起來(lái)是兩個(gè)不同的函數(shù)調(diào)用。而在編譯的時(shí)候，它們其實(shí)是同一個(gè)變量?

var_unit。

下劃線，一位真正的朋友

可以拿 _ 和 __ 作為標(biāo)示符。

混合多語(yǔ)言

隨機(jī)地混用兩種語(yǔ)言（人類(lèi)語(yǔ)言或計(jì)算機(jī)語(yǔ)言都行）。如果老板要求使用他指定的語(yǔ)言，你就告訴他你用自己的語(yǔ)言更有利于組織你的思路，萬(wàn)一這招不管用，就去控訴這是語(yǔ)言歧視，并威脅起訴老板要求巨額精神損失賠償。

擴(kuò)展 ASCII 字符

擴(kuò)展 ASCII 字符用于變量命名是完全合法的，包括 ?, D, 和 ? 等。在簡(jiǎn)單的文本編輯器里，除了拷貝/粘貼，基本上沒(méi)法輸入。

其他語(yǔ)言的命名

使用外語(yǔ)字典作為變量名的來(lái)源。例如，可以用德語(yǔ)單詞?punkt?代替?

point。除非維護(hù)代碼的程序員也像你一樣熟練掌握了德語(yǔ). 不然他就只能盡情地在代碼中享受異域風(fēng)情了。

數(shù)學(xué)命名

用數(shù)學(xué)操作符的單詞來(lái)命名變量。例如：

openParen?=?(slash?asterix)??/?equals;

(左圓括號(hào) = (斜杠 星號(hào))/等號(hào);)

令人眩暈的命名

用帶有完全不相關(guān)的感情色彩的單詞來(lái)命名變量。例如：

marypoppins?=?(superman?starship)??/?god;

(歡樂(lè)滿(mǎn)人間 = (超人 星河戰(zhàn)隊(duì))/上帝;)

這一招可以讓閱讀代碼的人陷入迷惑之中，因?yàn)樗麄冊(cè)谠噲D想清楚這些命名的邏輯時(shí)，會(huì)不自覺(jué)地聯(lián)系到不同的感情場(chǎng)景里而無(wú)法自拔。

何時(shí)使用 i

永遠(yuǎn)不要把??i?用作最內(nèi)層的循環(huán)變量。 用什么命名都行，就是別用?i

。把?

i

用在其他地方就隨便了，用作非整數(shù)變量尤其好。

慣例 -- 明修棧道，暗度陳倉(cāng)

忽視?Java 編碼慣例，Sun 就是這樣做的。幸運(yùn)的是，你違反了它編譯器也不會(huì)打小報(bào)告。這一招的目的是搞出一些在某些特殊情況下有細(xì)微差別的名字來(lái)。如果你被強(qiáng)迫遵循駝峰法命名，你還是可以在某些模棱兩可的情況下顛覆它。例如，input?F?ile?name?和?input?f?ile?N?ame?

兩個(gè)命名都可以合法使用。在此基礎(chǔ)上自己發(fā)明一套復(fù)雜到變態(tài)的命名慣例，然后就可以痛扁其他人，說(shuō)他們違反了慣例。

小寫(xiě)的 l 看上去很像數(shù)字 1

用小寫(xiě)字母 l 標(biāo)識(shí) long 常數(shù)。例如 10l 更容易被誤認(rèn)為是 101 而不是 10L 。 禁用所有能讓人準(zhǔn)確區(qū)分 uvw wW gq9 2z 5s il17|!j oO08 `'" ;,. m nn rn {[()]} 的字體。要做個(gè)有創(chuàng)造力的人。

把全局命名重用為私有

在A 模塊里聲明一個(gè)全局?jǐn)?shù)組，然后在B 模塊的頭文件里在聲明一個(gè)同名的私有數(shù)組，這樣看起來(lái)你在B 模塊里引用的是那個(gè)全局?jǐn)?shù)組，其實(shí)卻不是。不要在注釋里提到這個(gè)重復(fù)的情況。

誤導(dǎo)性的命名

讓每個(gè)方法都和它的名字蘊(yùn)含的功能有一些差異。例如，一個(gè)叫?

isValid(x)

的方法在判斷完參數(shù)x的合法性之后，還順帶著把它轉(zhuǎn)換成二進(jìn)制并保存到數(shù)據(jù)庫(kù)里。

偽裝

?

當(dāng)一個(gè)bug需要越長(zhǎng)的時(shí)間才會(huì)暴露，它就越難被發(fā)現(xiàn)。- Roedy Green（本文作者）

?

編寫(xiě)無(wú)法維護(hù)代碼的另一大秘訣就是偽裝的藝術(shù)，即隱藏它或者讓它看起來(lái)像其他東西。很多招式有賴(lài)于這樣一個(gè)事實(shí)：編譯器比肉眼或文本編輯器更有分辨能力。下面是一些偽裝的最佳招式。

把代碼偽裝成注釋，反之亦然

下面包括了一些被注釋掉的代碼，但是一眼看去卻像是正常代碼。 for(j?=?0; j?<?array_len; j ??=?8)

{

total??=?array?[?j 0??]?;?

total??=?array?[?j 1??]?;?

total??=?array?[?j 2??]?;?

total??=?array?[?j 6??]?;?

total??=?array?[?j 7??]?;?

}

如果不是用綠色標(biāo)出來(lái)，你能注意到這三行代碼被注釋掉了么？

用連接符隱藏變量

對(duì)于下面的定義

#define local_var xy_z

可以把 "xy_z" 打散到兩行里：

#define local_var xy\_z // local_var OK

這樣全局搜索 xy_z 的操作在這個(gè)文件里就一無(wú)所獲了。 對(duì)于 C 預(yù)處理器來(lái)說(shuō)，第一行最后的 "" 表示繼續(xù)拼接下一行的內(nèi)容。

文檔

任何傻瓜都能說(shuō)真話，而要把謊編圓則需要相當(dāng)?shù)闹腔邸? Samuel Butler (1835 - 1902)

不正確的文檔往往比沒(méi)有文檔還糟糕。- Bertrand Meyer

既然計(jì)算機(jī)是忽略注釋和文檔的，你就可以在里邊堂而皇之地編織彌天大謊，讓可憐的維護(hù)代碼的程序員徹底迷失。

在注釋中撒謊

實(shí)際上你不需要主動(dòng)地撒謊，只要沒(méi)有及時(shí)保持注釋和代碼更新的一致性就可以了。

只記錄顯而易見(jiàn)的東西

往代碼里摻進(jìn)去類(lèi)似于?這樣的注釋，但是永遠(yuǎn)不要記錄包或者方法的整體設(shè)計(jì)這樣的干貨。

記錄 How 而不是 Why

只解釋一個(gè)程序功能的細(xì)節(jié)，而不是它要完成的任務(wù)是什么。這樣的話，如果出現(xiàn)了一個(gè)bug，修復(fù)者就搞不清這里的代碼應(yīng)有的功能。

該寫(xiě)的別寫(xiě)

比如你在開(kāi)發(fā)一套航班預(yù)定系統(tǒng)，那就要精心設(shè)計(jì)，讓它在增加另一個(gè)航空公司的時(shí)候至少有25處代碼需要修改。永遠(yuǎn)不要在文檔里說(shuō)明要修改的位置。后來(lái)的開(kāi)發(fā)人員要想修改你的代碼門(mén)都沒(méi)有，除非他們能把每一行代碼都讀懂。

計(jì)量單位

永遠(yuǎn)不要在文檔中說(shuō)明任何變量、輸入、輸出或參數(shù)的計(jì)量單位，如英尺、米、加侖等。計(jì)量單位對(duì)數(shù)豆子不是太重要，但在工程領(lǐng)域就相當(dāng)重要了。同理，永遠(yuǎn)不要說(shuō)明任何轉(zhuǎn)換常量的計(jì)量單位，或者是它的取值如何獲得。要想讓代碼更亂的話，你還可以在注釋里寫(xiě)上錯(cuò)誤的計(jì)量單位，這是赤裸裸的欺騙，但是非常有效。如果你想做一個(gè)惡貫滿(mǎn)盈的人，不妨自己發(fā)明一套計(jì)量單位，用自己或某個(gè)小人物的名字命名這套計(jì)量單位，但不要給出定義。萬(wàn)一有人挑刺兒，你就告訴他們，你這么做是為了把浮點(diǎn)數(shù)運(yùn)算湊成整數(shù)運(yùn)算而進(jìn)行的轉(zhuǎn)換。

坑

永遠(yuǎn)不要記錄代碼中的坑。如果你懷疑某個(gè)類(lèi)里可能有bug，天知地知你知就好。如果你想到了重構(gòu)或重寫(xiě)代碼的思路，看在老天爺?shù)姆萆?#xff0c;千萬(wàn)別寫(xiě)出來(lái)。切記電影《小鹿斑比》里那句臺(tái)詞?"如果你不能說(shuō)好聽(tīng)的話，那就什么也不要說(shuō)。"。萬(wàn)一這段代碼的原作者看到你的注釋怎么辦？萬(wàn)一老板看到了怎么辦？萬(wàn)一客戶(hù)看到了怎么辦？搞不好最后你自己被解雇了。一句”這里需要修改“的匿名注釋就好多了，尤其是當(dāng)看不清這句注釋指的是哪里需要修改的情況下。切記難得糊涂四個(gè)字，這樣大家都不會(huì)感覺(jué)受到了批評(píng)。

說(shuō)明變量

永遠(yuǎn)不要?對(duì)變量聲明加注釋。有關(guān)變量使用的方式、邊界值、合法值、小數(shù)點(diǎn)后的位數(shù)、計(jì)量單位、顯示格式、數(shù)據(jù)錄入規(guī)則等等，后繼者完全可以自己從程序代碼中去理解和整理嘛。如果老板強(qiáng)迫你寫(xiě)注釋，就把方法體代碼混進(jìn)去，但絕對(duì)不要對(duì)變量聲明寫(xiě)注釋，即使是臨時(shí)變量！

在注釋里挑撥離間

為了阻撓任何雇傭外部維護(hù)承包商的傾向，可以在代碼中散布針對(duì)其他同行軟件公司的攻擊和抹黑，特別是可能接替你工作的其中任何一家。例如： class??clever_SSInc

{

.?.?.

}

可能的話，除了注釋之外，這些攻擊抹黑的內(nèi)容也要摻到代碼里的重要部分，這樣如果管理層想清理掉這些攻擊性的言論然后發(fā)給外部承包商去維護(hù)，就會(huì)破壞代碼結(jié)構(gòu)。

程序設(shè)計(jì)

編寫(xiě)無(wú)法維護(hù)代碼的基本規(guī)則就是：在盡可能多的地方，以盡可能多的方式表述每一個(gè)事實(shí)。- Roedy Green

編寫(xiě)可維護(hù)代碼的關(guān)鍵因素是只在一個(gè)地方表述應(yīng)用里的一個(gè)事實(shí)。如果你的想法變了，你也只在一個(gè)地方修改，這樣就能保證整個(gè)程序正常工作。所以，編寫(xiě)無(wú)法維護(hù)代碼的關(guān)鍵因素就是反復(fù)地表述同一個(gè)事實(shí)，在盡可能多的地方，以盡可能多的方式進(jìn)行。令人高興的是，像Java這樣的語(yǔ)言讓編寫(xiě)這種無(wú)法維護(hù)代碼變得非常容易。例如，改變一個(gè)被引用很多的變量的類(lèi)型幾乎是不可能的，因?yàn)樗性煨秃娃D(zhuǎn)換功能都會(huì)出錯(cuò)，而且關(guān)聯(lián)的臨時(shí)變量的類(lèi)型也不合適了。而且，如果變量值要在屏幕上顯示，那么所有相關(guān)的顯示和數(shù)據(jù)錄入代碼都必須一一找到并手工進(jìn)行修改。類(lèi)似的還有很多，比如由C和Java組成的Algol語(yǔ)言系列，Abundance甚至Smalltalk對(duì)于數(shù)組等結(jié)構(gòu)的處理，都是大有可為的。

Java 造型

Java的造型機(jī)制是上帝的禮物。你可以問(wèn)心無(wú)愧地使用它，因?yàn)镴ava語(yǔ)言本身就需要它。每次你從一個(gè)Collection 里獲取一個(gè)對(duì)象，你都必須把它造型為原始類(lèi)型。這樣這個(gè)變量的類(lèi)型就必須在無(wú)數(shù)地方表述。如果后來(lái)類(lèi)型變了，所有的造型都要修改才能匹配。如果倒霉的維護(hù)代碼的程序員沒(méi)有找全（或者修改太多），編譯器能不能檢測(cè)到也不好說(shuō)。類(lèi)似的，如果變量類(lèi)型從?short?變成??int?，所有匹配的造型也都要從(short)

改成?

(int)

。

利用Java的冗余

Java要求你給每個(gè)變量的類(lèi)型寫(xiě)兩次表述。 Java 程序員已經(jīng)習(xí)慣了這種冗余，他們不會(huì)注意到你的兩次表述有細(xì)微的差別，例如

Bubblegum?b?=?new?Bubblegom();

不幸的是 操作符的盛行讓下面這種偽冗余代碼得手的難度變大了：

swimmer?=?swimner?1;

永遠(yuǎn)不做校驗(yàn)

永遠(yuǎn)不要對(duì)輸入數(shù)據(jù)做任何的正確性或差異性檢查。這樣能表現(xiàn)你對(duì)公司設(shè)備的絕對(duì)信任，以及你是一位信任所有項(xiàng)目伙伴和系統(tǒng)管理員的團(tuán)隊(duì)合作者?？偸欠祷睾侠淼闹?#xff0c;即使數(shù)據(jù)輸入有問(wèn)題或者錯(cuò)誤。

有禮貌，無(wú)斷言

避免使用 assert() 機(jī)制，因?yàn)樗赡馨讶斓膁ebug盛宴變成10分鐘的快餐。

避免封裝

為了提高效率，不要使用封裝。方法的調(diào)用者需要所有能得到的外部信息，以便了解方法的內(nèi)部是如何工作的。

復(fù)制粘貼修改

以效率的名義，使用 復(fù)制 粘貼 修改。這樣比寫(xiě)成小型可復(fù)用模塊效率高得多。在用代碼行數(shù)衡量你的進(jìn)度的小作坊里，這招尤其管用。

使用靜態(tài)數(shù)組

如果一個(gè)庫(kù)里的模塊需要一個(gè)數(shù)組來(lái)存放圖片，就定義一個(gè)靜態(tài)數(shù)組。沒(méi)人會(huì)有比512 X 512 更大的圖片，所以固定大小的數(shù)組就可以了。為了最佳精度，就把它定義成 double 類(lèi)型的數(shù)組。

傻瓜接口

編寫(xiě)一個(gè)名為 "WrittenByMe" 之類(lèi)的空接口，然后讓你的所有類(lèi)都實(shí)現(xiàn)它。然后給所有你用到的Java 內(nèi)置類(lèi)編寫(xiě)包裝類(lèi)。這里的思想是確保你程序里的每個(gè)對(duì)象都實(shí)現(xiàn)這個(gè)接口。最后，編寫(xiě)所有的方法，讓它們的參數(shù)和返回類(lèi)型都是這個(gè) WrittenByMe。這樣就幾乎不可能搞清楚某個(gè)方法的功能是什么，并且所有類(lèi)型都需要好玩的造型方法。更出格的玩法是，讓每個(gè)團(tuán)隊(duì)成員編寫(xiě)它們自己的接口(例如 WrittenByJoe)，程序員用到的任何類(lèi)都要實(shí)現(xiàn)他自己的接口。這樣你就可以在大量無(wú)意義接口中隨便找一個(gè)來(lái)引用對(duì)象了。

巨型監(jiān)聽(tīng)器

永遠(yuǎn)不要為每個(gè)組件創(chuàng)建分開(kāi)的監(jiān)聽(tīng)器。對(duì)所有按鈕總是用同一個(gè)監(jiān)聽(tīng)器，只要用大量的if...else 來(lái)判斷是哪一個(gè)按鈕被點(diǎn)擊就行了。

好事成堆TM

狂野地使用封裝和OO思想。例如

myPanel?.?add( getMyButton?(?)?);?

private?JButton??getMyButton

()

{

return?myButton;?

}

這段很可能看起來(lái)不怎么好笑。別擔(dān)心，只是時(shí)候未到而已。

友好的朋友

在C 里盡量多使用friend聲明。再把創(chuàng)建類(lèi)的指針傳遞給已創(chuàng)建類(lèi)?，F(xiàn)在你不用浪費(fèi)時(shí)間去考慮接口了。另外，你應(yīng)該用上關(guān)鍵字private?和?protected?

來(lái)表明你的類(lèi)封裝得很好。

使用三維數(shù)組

大量使用它們。用扭曲的方式在數(shù)組之間移動(dòng)數(shù)據(jù)，比如，用arrayA里的行去填充arrayB的列。這么做的時(shí)候，不管三七二十一再加上1的偏移值，這樣很靈。讓維護(hù)代碼的程序員抓狂去吧。

混合與匹配

存取方法和公共變量神馬的都要給他用上。這樣的話，你無(wú)需調(diào)用存取器的開(kāi)銷(xiāo)就可以修改一個(gè)對(duì)象的變量，還能宣稱(chēng)這個(gè)類(lèi)是個(gè)"Java Bean"。對(duì)于那些試圖添加日志函數(shù)來(lái)找出改變值的源頭的維護(hù)代碼的程序員，用這一招來(lái)迷惑他尤其有效。

沒(méi)有秘密!

把每個(gè)方法和變量都聲明為 public。畢竟某個(gè)人某天可能會(huì)需要用到它。一旦方法被聲明為public 了，就很難縮回去。對(duì)不？這樣任何它覆蓋到的代碼都很難修改了。它還有個(gè)令人愉快的副作用，就是讓你看不清類(lèi)的作用是什么。如果老板質(zhì)問(wèn)你是不是瘋了，你就告訴他你遵循的是經(jīng)典的透明接口原則。

全堆一塊

把你所有的沒(méi)用的和過(guò)時(shí)的方法和變量都留在代碼里。畢竟說(shuō)起來(lái)，既然你在1976年用過(guò)一次，誰(shuí)知道你啥時(shí)候會(huì)需要再用到呢？當(dāng)然程序是改了，但它也可能會(huì)改回來(lái)嘛，你"不想要重新發(fā)明輪子"（領(lǐng)導(dǎo)們都會(huì)喜歡這樣的口氣）。如果你還原封不動(dòng)地留著這些方法和變量的注釋，而且注釋寫(xiě)得又高深莫測(cè)，甭管維護(hù)代碼的是誰(shuí)，恐怕都不敢對(duì)它輕舉妄動(dòng)。

就是 Final

把你所有的葉子類(lèi)都聲明為 final。畢竟說(shuō)起來(lái)，你在項(xiàng)目里的活兒都干完了，顯然不會(huì)有其他人會(huì)通過(guò)擴(kuò)展你的類(lèi)來(lái)改進(jìn)你的代碼。這種情況甚至可能有安全漏洞。 java.lang.String 被定義成 final 也許就是這個(gè)原因吧？如果項(xiàng)目組其他程序員有意見(jiàn)，告訴他們這樣做能夠提高運(yùn)行速度。

避免布局

永遠(yuǎn)不要用到布局。當(dāng)維護(hù)代碼的程序員想增加一個(gè)字段，他必須手工調(diào)整屏幕上顯示所有內(nèi)容的絕對(duì)坐標(biāo)值。如果老板強(qiáng)迫你使用布局，那就寫(xiě)一個(gè)巨型的 GridBagLayout 并在里面用絕對(duì)坐標(biāo)進(jìn)行硬編碼。

全局變量，怎么強(qiáng)調(diào)都不過(guò)分

如果上帝不愿意我們使用全局變量，他就不會(huì)發(fā)明出這個(gè)東西。不要讓上帝失望，盡量多使用全局變量。每個(gè)函數(shù)最起碼都要使用和設(shè)置其中的兩個(gè)，即使沒(méi)有理由也要這么做。畢竟，任何優(yōu)秀的維護(hù)代碼的程序員都會(huì)很快搞清楚這是一種偵探工作測(cè)試，有利于讓他們從笨蛋中脫穎而出。

再一次說(shuō)說(shuō)全局變量

全局變量讓你可以省去在函數(shù)里描述參數(shù)的麻煩。充分利用這一點(diǎn)。在全局變量中選那么幾個(gè)來(lái)表示對(duì)其他全局變量進(jìn)行操作的類(lèi)型。

局部變量

永遠(yuǎn)不要用局部變量。在你感覺(jué)想要用的時(shí)候，把它改成一個(gè)實(shí)例或者靜態(tài)變量，并無(wú)私地和其他方法分享它。這樣做的好處是，你以后在其他方法里寫(xiě)類(lèi)似聲明的時(shí)候會(huì)節(jié)省時(shí)間。C 程序員可以百尺竿頭更進(jìn)一步，把所有變量都弄成全局的。

配置文件

配置文件通常是以 關(guān)鍵字 = 值 的形式出現(xiàn)。在加載時(shí)這些值被放入 Java 變量中。最明顯的迷惑技術(shù)就是把有細(xì)微差別的名字用于關(guān)鍵字和Java 變量.甚至可以在配置文件里定義運(yùn)行時(shí)根本不會(huì)改變的常量。參數(shù)文件變量和簡(jiǎn)單變量比，維護(hù)它的代碼量起碼是后者的5倍。

子類(lèi)

對(duì)于編寫(xiě)無(wú)法維護(hù)代碼的任務(wù)來(lái)說(shuō)，面向?qū)ο缶幊痰乃枷牒?jiǎn)直是天賜之寶。如果你有一個(gè)類(lèi)，里邊有10個(gè)屬性（成員/方法），可以考慮寫(xiě)一個(gè)基類(lèi)，里面只有一個(gè)屬性，然后產(chǎn)生9層的子類(lèi)，每層增加一個(gè)屬性。等你訪問(wèn)到最終的子類(lèi)時(shí)，你才能得到全部10個(gè)屬性。如果可能，把每個(gè)類(lèi)的聲明都放在不同的文件里。

編碼迷局

迷惑 C

從互聯(lián)網(wǎng)上的各種混亂C 語(yǔ)言競(jìng)賽中學(xué)習(xí)，追隨大師們的腳步。

追求極致

總是追求用最迷惑的方式來(lái)做普通的任務(wù)。例如，要用數(shù)組來(lái)把整數(shù)轉(zhuǎn)換為相應(yīng)的字符串，可以這么做：

char *p;

switch (n)?

{?

case 1:?

p = "one";?

if (0)?

case 2:?

p = "two";?

if (0)?

case 3:?

p = "three";?

printf("%s", p);?

break;?

}

一致性的小淘氣

當(dāng)你需要一個(gè)字符常量的時(shí)候，可以用多種不同格式： ' ', 32, 0x20, 040。在C或Java里10和010是不同的數(shù)（0開(kāi)頭的表示16進(jìn)制），你也可以充分利用這個(gè)特性。

造型

把所有數(shù)據(jù)都以 void * 形式傳遞，然后再造型為合適的結(jié)構(gòu)。不用結(jié)構(gòu)而是通過(guò)位移字節(jié)數(shù)來(lái)造型也很好玩。

嵌套 Switch

Switch 里邊還有 Switch，這種嵌套方式是人類(lèi)大腦難以破解的。

利用隱式轉(zhuǎn)化

牢記編程語(yǔ)言中所有的隱式轉(zhuǎn)化細(xì)節(jié)。充分利用它們。數(shù)組的索引要用浮點(diǎn)變量，循環(huán)計(jì)數(shù)器用字符，對(duì)數(shù)字執(zhí)行字符串函數(shù)調(diào)用。不管怎么說(shuō)，所有這些操作都是合法的，它們無(wú)非是讓源代碼更簡(jiǎn)潔而已。任何嘗試?yán)斫馑鼈兊木S護(hù)者都會(huì)對(duì)你感激不盡，因?yàn)樗麄儽仨氶喿x和學(xué)習(xí)整個(gè)關(guān)于隱式數(shù)據(jù)類(lèi)型轉(zhuǎn)化的章節(jié)，而這個(gè)章節(jié)很可能是他們來(lái)維護(hù)你的代碼之前完全忽略了的。

分號(hào)!

在所有語(yǔ)法允許的地方都加上分號(hào)，例如：

if(a);

else;

{

int??d?;?

d??=?c;?

}?

;

使用八進(jìn)制數(shù)

把八進(jìn)制數(shù)混到十進(jìn)制數(shù)列表里，就像這樣：

array?=?new?int??[?]

{

111?,

120?,

013?,

121?,

};

嵌套

盡可能深地嵌套。優(yōu)秀的程序員能在一行代碼里寫(xiě)10層()，在一個(gè)方法里寫(xiě)20層{}。

C數(shù)組

C編譯器會(huì)把??myArray??轉(zhuǎn)換成??*(myArray i)?，它等同于??*(i myArray)

也等同于?

i[myArray]

。 高手都知道怎么用好這個(gè)招。可以用下面的函數(shù)來(lái)產(chǎn)生索引，這樣就把代碼搞亂了：

int myfunc(int q, int p) { return p%q; }??
...??
myfunc(6291, 8)[Array];

遺憾的是，這一招只能在本地C類(lèi)里用，Java 還不行。

放長(zhǎng)線釣大魚(yú)

一行代碼里堆的東西越多越好。這樣可以省下臨時(shí)變量的開(kāi)銷(xiāo)，去掉換行和空格還可以縮短源文件大小。記住，要去掉運(yùn)算符兩邊的空格。優(yōu)秀的程序員總是能突破某些編輯器對(duì)于255個(gè)字符行寬的限制。

異常

我這里要向你傳授一個(gè)編程中鮮為人知的秘訣。異常是個(gè)討厭的東西。良好的代碼永遠(yuǎn)不會(huì)出錯(cuò)，所以異常實(shí)際上是不必要的。不要把時(shí)間浪費(fèi)在這上面。子類(lèi)異常是給那些知道自己代碼會(huì)出錯(cuò)的低能兒用的。在整個(gè)應(yīng)用里，你只用在main()里放一個(gè)try/catch，里邊直接調(diào)用 System.exit()就行了。在每個(gè)方法頭要貼上標(biāo)準(zhǔn)的拋出集合定義，到底會(huì)不會(huì)拋出異常你就不用管了。

使用異常的時(shí)機(jī)

在非異常條件下才要使用異常。比如終止循環(huán)就可以用?

ArrayIndexOutOfBoundsException

。還可以從異常里的方法返回標(biāo)準(zhǔn)的結(jié)果。

狂熱奔放地使用線程

如題。

測(cè)試

在程序里留些bug，讓后繼的維護(hù)代碼的程序員能做點(diǎn)有意思的事。精心設(shè)計(jì)的bug是無(wú)跡可尋的，而且誰(shuí)也不知道它啥時(shí)候會(huì)冒出來(lái)。要做到這一點(diǎn)，最簡(jiǎn)單的辦法的就是不要測(cè)試代碼。

永不測(cè)試

永遠(yuǎn)不要測(cè)試負(fù)責(zé)處理錯(cuò)誤、當(dāng)機(jī)或操作系故障的任何代碼。反正這些代碼永遠(yuǎn)也不會(huì)執(zhí)行，只會(huì)拖累你的測(cè)試。還有，你怎么可能測(cè)試處理磁盤(pán)錯(cuò)誤、文件讀取錯(cuò)誤、操作系統(tǒng)崩潰這些類(lèi)型的事件呢？為啥你要用特別不穩(wěn)定的計(jì)算機(jī)或者用測(cè)試腳手架來(lái)模擬這樣的環(huán)境？現(xiàn)代化的硬件永遠(yuǎn)不會(huì)崩潰，誰(shuí)還愿意寫(xiě)一些僅僅用于測(cè)試的代碼？這一點(diǎn)也不好玩。如果用戶(hù)抱怨，你就怪到操作系統(tǒng)或者硬件頭上。他們永遠(yuǎn)不會(huì)知道真相的。

永遠(yuǎn)不要做性能測(cè)試

嘿，如果軟件運(yùn)行不夠快，只要告訴客戶(hù)買(mǎi)個(gè)更快的機(jī)器就行了。如果你真的做了性能測(cè)試，你可能會(huì)發(fā)現(xiàn)一個(gè)瓶頸，這會(huì)導(dǎo)致修改算法，然后導(dǎo)致整個(gè)產(chǎn)品要重新設(shè)計(jì)。誰(shuí)想要這種結(jié)果？而且，在客戶(hù)那邊發(fā)現(xiàn)性能問(wèn)題意味著你可以免費(fèi)到外地旅游。你只要備好護(hù)照和最新照片就行了。

永遠(yuǎn)不要寫(xiě)任何測(cè)試用例

永遠(yuǎn)不要做代碼覆蓋率或路徑覆蓋率測(cè)試。自動(dòng)化測(cè)試是給那些窩囊廢用的。搞清楚哪些特性占到你的例程使用率的90%，然后把90%的測(cè)試用在這些路徑上。畢竟說(shuō)起來(lái)，這種方法可能只測(cè)試到了大約你代碼的60%，這樣你就節(jié)省了40%的測(cè)試工作。這能幫助你趕上項(xiàng)目后端的進(jìn)度。等到有人發(fā)現(xiàn)所有這些漂亮的“市場(chǎng)特性”不能正常工作的時(shí)候，你早就跑路了。一些有名的大軟件公司就是這樣測(cè)試代碼的，所以你也應(yīng)該這樣做。如果因?yàn)槟撤N原因你還沒(méi)走，那就接著看下一節(jié)。

測(cè)試是給懦夫用的

勇敢的程序員會(huì)跳過(guò)這個(gè)步驟。太多程序員害怕他們的老板，害怕丟掉工作，害怕客戶(hù)的投訴郵件，害怕遭到起訴。這種恐懼心理麻痹了行動(dòng)，降低了生產(chǎn)率。有科學(xué)研究成果表明，取消測(cè)試階段意味著經(jīng)理有把握能提前確定交付時(shí)間，這對(duì)于規(guī)劃流程顯然是有利的。消除了恐懼心理，創(chuàng)新和實(shí)驗(yàn)之花就隨之綻放。程序員的角色是生產(chǎn)代碼，調(diào)試工作完全可以由技術(shù)支持和遺留代碼維護(hù)組通力合作來(lái)進(jìn)行。

如果我們對(duì)自己的編程能力有充分信心，那么測(cè)試就沒(méi)有必要了。如果我們邏輯地看待這個(gè)問(wèn)題，隨便一個(gè)傻瓜都能認(rèn)識(shí)到測(cè)試根本都不是為了解決技術(shù)問(wèn)題，相反，它是一種感性的信心問(wèn)題。針對(duì)這種缺乏信心的問(wèn)題，更有效的解決辦法就是完全取消測(cè)試，送我們的程序員去參加自信心培訓(xùn)課程。畢竟說(shuō)起來(lái)，如果我們選擇做測(cè)試，那么我們就要測(cè)試每個(gè)程序的變更，但其實(shí)我們只需要送程序員去一次建立自信的培訓(xùn)課就行了。很顯然這么做的成本收益是相當(dāng)可觀的。

編程語(yǔ)言的選擇

計(jì)算機(jī)語(yǔ)言正在逐步進(jìn)化，變得更加傻瓜化。使用最新的語(yǔ)言是不人性的。盡可能堅(jiān)持使用你會(huì)用的最老的語(yǔ)言，先考慮用穿孔紙帶，不行就用匯編，再不行用FORTRAN 或者 COBOL，再不行就用C 還有 BASIC，實(shí)在不行再用 C 。

F?RTRAN

用 FORTRAN 寫(xiě)所有的代碼。如果老板問(wèn)你為啥，你可以回答說(shuō)有很多它非常有用的庫(kù)，你用了可以節(jié)約時(shí)間。不過(guò)，用 FORTRAN 寫(xiě)出可維護(hù)代碼的概率是0，所以，要達(dá)到不可維護(hù)代碼編程指南里的要求就容易多了。

用 ASM

把所有的通用工具函數(shù)都轉(zhuǎn)成匯編程序。

用 QBASIC

所有重要的庫(kù)函數(shù)都要用 QBASIC 寫(xiě)，然后再寫(xiě)個(gè)匯編的封包程序來(lái)處理 large 到 medium 的內(nèi)存模型映射。

內(nèi)聯(lián)匯編

在你的代碼里混雜一些內(nèi)聯(lián)的匯編程序，這樣很好玩。這年頭幾乎沒(méi)人懂匯編程序了。只要放幾行匯編代碼就能讓維護(hù)代碼的程序員望而卻步。

宏匯編調(diào)用C

如果你有個(gè)匯編模塊被C調(diào)用，那就盡可能經(jīng)常從匯編模塊再去調(diào)用C，即使只是出于微不足道的用途，另外要充分利用 goto, bcc 和其他炫目的匯編秘籍。

與他人共事之道

老板才是真行家

如果你的老板認(rèn)為他20年的 FORTRAN 編程經(jīng)驗(yàn)對(duì)于現(xiàn)代軟件開(kāi)發(fā)具有很高的指導(dǎo)價(jià)值，你務(wù)必嚴(yán)格采納他的所有建議。投桃報(bào)李，你的老板也會(huì)信任你。這會(huì)對(duì)你的職業(yè)發(fā)展有利。你還會(huì)從他那里學(xué)到很多搞亂程序代碼的新方法。

顛覆技術(shù)支持

確保代碼中到處是bug的有效方法是永遠(yuǎn)不要讓維護(hù)代碼的程序員知道它們。這需要顛覆技術(shù)支持工作。永遠(yuǎn)不接電話。使用自動(dòng)語(yǔ)音答復(fù)“感謝撥打技術(shù)支持熱線。需要人工服務(wù)請(qǐng)按1，或在嘀聲后留言。”，請(qǐng)求幫助的電子郵件必須忽略，不要給它分配服務(wù)追蹤號(hào)。對(duì)任何問(wèn)題的標(biāo)準(zhǔn)答復(fù)是“我估計(jì)你的賬戶(hù)被鎖定了，有權(quán)限幫你恢復(fù)的人現(xiàn)在不在?！?

沉默是金

永遠(yuǎn)不要對(duì)下一個(gè)危機(jī)保持警覺(jué)。如果你預(yù)見(jiàn)到某個(gè)問(wèn)題可能會(huì)在一個(gè)固定時(shí)間爆發(fā)，摧毀西半球的全部生命，不要公開(kāi)討論它。不要告訴朋友、同事或其他你認(rèn)識(shí)的有本事的人。在任何情況下都不要發(fā)表任何可能暗示到這種新的威脅的內(nèi)容。只發(fā)送一篇正常優(yōu)先級(jí)的、語(yǔ)焉不詳?shù)膫渫浗o管理層，保護(hù)自己免遭秋后算賬。如果可能的話，把這篇稀里糊涂的信息作為另外一個(gè)更緊急的業(yè)務(wù)問(wèn)題的附件。這樣就可以心安理得地休息了，你知道將來(lái)你被強(qiáng)制提前退休之后一段時(shí)間，他們又會(huì)求著你回來(lái)，并給你對(duì)數(shù)級(jí)增長(zhǎng)的時(shí)薪！

每月一書(shū)俱樂(lè)部

加入一個(gè)計(jì)算機(jī)每月一書(shū)俱樂(lè)部。選擇那些看上去忙著寫(xiě)書(shū)不可能有時(shí)間真的去寫(xiě)代碼的作者。去書(shū)店里找一些有很多圖表但是沒(méi)有代碼例子的書(shū)。瀏覽一下這些書(shū)，從中學(xué)會(huì)一些迂腐拗口的術(shù)語(yǔ)，用它們就能唬住那些自以為是的維護(hù)代碼的程序員。你的代碼肯定會(huì)給他留下深刻印象。如果人們連你寫(xiě)的術(shù)語(yǔ)都理解不了，他們一定會(huì)認(rèn)為你非常聰明，你的算法非常深?yuàn)W。不要在你的算法說(shuō)明里作任何樸素的類(lèi)比。

自立門(mén)戶(hù)

你一直想寫(xiě)系統(tǒng)級(jí)的代碼。現(xiàn)在機(jī)會(huì)來(lái)了。忽略標(biāo)準(zhǔn)庫(kù)，?

編寫(xiě)你自己的標(biāo)準(zhǔn)

，這將會(huì)是你簡(jiǎn)歷中的一個(gè)亮點(diǎn)。

推出你自己的 BNF 范式

總是用你自創(chuàng)的、獨(dú)一無(wú)二的、無(wú)文檔的BNF范式記錄你的命令語(yǔ)法。永遠(yuǎn)不要提供一套帶注解的例子（合法命令和非法命令之類(lèi)）來(lái)解釋你的語(yǔ)法體系。那樣會(huì)顯得完全缺乏學(xué)術(shù)嚴(yán)謹(jǐn)性。確保沒(méi)有明顯的方式來(lái)區(qū)分終結(jié)符和中間符號(hào)。永遠(yuǎn)不要用字體、顏色、大小寫(xiě)和其他任何視覺(jué)提示幫助讀者分辨它們。在你的 BNF 范式用和命令語(yǔ)言本身完全一樣的標(biāo)點(diǎn)符號(hào)，這樣讀者就永遠(yuǎn)無(wú)法分清一段 (...), [...], {...} 或 "..." 到底是你在命令行里真正輸入的，還是想提示在你的BNF 范式里哪個(gè)語(yǔ)法元素是必需的、可重復(fù)的、或可選的。不管怎么樣，如果他們太笨，搞不清你的BNF 范式的變化，就沒(méi)資格使用你的程序。

推出你自己的內(nèi)存分配

地球人兒都知道，調(diào)試動(dòng)態(tài)存儲(chǔ)是復(fù)雜和費(fèi)時(shí)的。與其逐個(gè)類(lèi)去確認(rèn)它沒(méi)有內(nèi)存溢出，還不如自創(chuàng)一套存儲(chǔ)分配機(jī)制呢。其實(shí)它無(wú)非是從一大片內(nèi)存中 malloc 一塊空間而已。用不著釋放內(nèi)存，讓用戶(hù)定期重啟動(dòng)系統(tǒng)，這樣不就清除了堆么。重啟之后系統(tǒng)需要追蹤的就那么一點(diǎn)東西，比起解決所有的內(nèi)存泄露簡(jiǎn)單得不知道到哪里去了！而且，只要用戶(hù)記得定期重啟系統(tǒng)，他們也永遠(yuǎn)不會(huì)遇到堆空間不足的問(wèn)題。一旦系統(tǒng)被部署，你很難想象他們還能改變這個(gè)策略。

其他雜七雜八的招

?

如果你給某人一段程序，你會(huì)讓他困惑一天；如果你教他們?nèi)绾尉幊?#xff0c;你會(huì)讓他困惑一輩子。-- Anonymous

?

不要重編譯

讓我們從一條可能是有史以來(lái)最友好的技巧開(kāi)始：把代碼編譯成可執(zhí)行文件。如果它能用，就在源代碼里做一兩個(gè)微小的改動(dòng) -- 每個(gè)模塊都照此辦理。?但是不要費(fèi)勁巴拉地再編譯一次了。??你可以留著等以后有空而且需要調(diào)試的時(shí)候再說(shuō)。多年以后，等可憐的維護(hù)代碼的程序員更改了代碼之后發(fā)現(xiàn)出錯(cuò)了，他會(huì)有一種錯(cuò)覺(jué)，覺(jué)得這些肯定是他自己最近修改的。這樣你就能讓他毫無(wú)頭緒地忙碌很長(zhǎng)時(shí)間。

挫敗調(diào)試工具

對(duì)于試圖用行調(diào)試工具追蹤來(lái)看懂你的代碼的人，簡(jiǎn)單的一招就能讓他狼狽不堪，那就是把每一行代碼都寫(xiě)得很長(zhǎng)。特別要把 then 語(yǔ)句 和 if 語(yǔ)句放在同一行里。他們無(wú)法設(shè)置斷點(diǎn)。他們也無(wú)法分清在看的分支是哪個(gè) if 里的。

公制和美制

在工程方面有兩種編碼方式。一種是把所有輸入都轉(zhuǎn)換為公制（米制）計(jì)量單位，然后在輸出的時(shí)候自己換算回各種民用計(jì)量單位。另一種是從頭到尾都保持各種計(jì)量單位混合在一起。總是選擇第二種方式，這就是美國(guó)之道！

持續(xù)改進(jìn)

要持續(xù)不懈地改進(jìn)。要常常對(duì)你的代碼做出“改進(jìn)”，并強(qiáng)迫用戶(hù)經(jīng)常升級(jí) -- 畢竟沒(méi)人愿意用一個(gè)過(guò)時(shí)的版本嘛。即便他們覺(jué)得他們對(duì)現(xiàn)有的程序滿(mǎn)意了，想想看，如果他們看到你又“完善“了它，他們會(huì)多么開(kāi)心啊！不要告訴任何人版本之間的差別，除非你被逼無(wú)奈 -- 畢竟，為什么要告訴他們本來(lái)永遠(yuǎn)也不會(huì)注意到的一些bug呢？

”關(guān)于“

”關(guān)于“一欄應(yīng)該只包含程序名、程序員姓名和一份用法律用語(yǔ)寫(xiě)的版權(quán)聲明。理想情況下，它還應(yīng)該鏈接到幾 MB 的代碼，產(chǎn)生有趣的動(dòng)畫(huà)效果。但是，里邊永遠(yuǎn)不要包含程序用途的描述、它的版本號(hào)、或最新代碼修改日期、或獲取更新的網(wǎng)站地址、或作者的email地址等。這樣，所有的用戶(hù)很快就會(huì)運(yùn)行在不同的版本上，在安裝N 1版之前就試圖安裝N 2版。

變更

在兩個(gè)版本之間，你能做的變更自然是多多益善。你不會(huì)希望用戶(hù)年復(fù)一年地面對(duì)同一套老的接口或用戶(hù)界面，這樣會(huì)很無(wú)聊。最后，如果你能在用戶(hù)不注意的情況下做出這些變更，那就更好了 -- 這會(huì)讓他們保持警惕，戒驕戒躁。

無(wú)需技能

寫(xiě)無(wú)法維護(hù)代碼不需要多高的技能。喊破嗓子不如甩開(kāi)膀子，不管三七二十一開(kāi)始寫(xiě)代碼就行了。記住，管理層還在按代碼行數(shù)考核生產(chǎn)率，即使以后這些代碼里的大部分都得刪掉。

只帶一把錘子

一招鮮吃遍天，輕裝前進(jìn)。如果你手頭只有一把錘子，那么所有的問(wèn)題都是釘子。

規(guī)范體系

有可能的話，忽略當(dāng)前你的項(xiàng)目所用語(yǔ)言和環(huán)境中被普羅大眾所接受的編程規(guī)范。比如，編寫(xiě)基于MFC 的應(yīng)用時(shí)，就堅(jiān)持使用STL 編碼風(fēng)格。

翻轉(zhuǎn)通常的 True False 慣例

把常用的 true 和 false 的定義反過(guò)來(lái)用。這一招聽(tīng)起來(lái)平淡無(wú)奇，但是往往收獲奇效。你可以先藏好下面的定義：

#define TRUE 0#define FALSE 1

把這個(gè)定義深深地藏在代碼中某個(gè)沒(méi)人會(huì)再去看的文件里不易被發(fā)現(xiàn)的地方，然后讓程序做下面這樣的比較

if ( var == TRUE )

if ( var != FALSE )

某些人肯定會(huì)迫不及待地跳出來(lái)“修正”這種明顯的冗余，并且在其他地方照著常規(guī)去使用變量var：

if ( var )

還有一招是為??TRUE??和??FALSE?賦予相同的值，雖然大部分人可能會(huì)看穿這種騙局。給它們分別賦值 1 和 2 或者 -1 和 0 是讓他們瞎忙乎的方式里更精巧的，而且這樣做看起來(lái)也不失對(duì)他們的尊重。你在Java 里也可以用這一招，定義一個(gè)叫?TRUE??

的靜態(tài)常量。在這種情況下，其他程序員更有可能懷疑你干的不是好事，因?yàn)镴ava里已經(jīng)有了內(nèi)建的標(biāo)識(shí)符?

true

。

第三方庫(kù)

在你的項(xiàng)目里引入功能強(qiáng)大的第三方庫(kù)，然后不要用它們。潛規(guī)則就是這樣，雖然你對(duì)這些好的工具仍然一無(wú)所知，卻還是可以在你簡(jiǎn)歷的“其他工具”一節(jié)中寫(xiě)上這些沒(méi)用過(guò)的庫(kù)。

不要用庫(kù)

假裝不知道有些庫(kù)已經(jīng)直接在你的開(kāi)發(fā)工具中引入了。如果你用VC 編程，忽略MFC 或 STL 的存在，手工編寫(xiě)所有字符串和數(shù)組的實(shí)現(xiàn)；這樣有助于保持你的指針技術(shù)，并自動(dòng)阻止任何擴(kuò)展代碼功能的企圖。

創(chuàng)建一套Build順序

把這套順序規(guī)則做得非?；逎?#xff0c;讓維護(hù)者根本無(wú)法編譯任何他的修改代碼。秘密保留?SmartJ?，它會(huì)讓??make?腳本形同廢物。類(lèi)似地，偷偷地定義一個(gè)??javac??類(lèi)，讓它和編譯程序同名。說(shuō)到大招，那就是編寫(xiě)和維護(hù)一個(gè)定制的小程序，在程序里找到需要編譯的文件，然后通過(guò)直接調(diào)用??sun.tools.javac.Main??編譯類(lèi)來(lái)進(jìn)行編譯。

Make 的更多玩法

用一個(gè) makefile-generated-batch-file 批處理文件從多個(gè)目錄復(fù)制源文件，文件之間的覆蓋規(guī)則在文檔中是沒(méi)有的。這樣，無(wú)需任何炫酷的源代碼控制系統(tǒng)，就能實(shí)現(xiàn)代碼分支，并阻止你的后繼者弄清哪個(gè)版本的 DoUsefulWork() 才是他需要修改的那個(gè)。

搜集編碼規(guī)范

盡可能搜集所有關(guān)于編寫(xiě)可維護(hù)代碼的建議，例如?SquareBox 的建議?，然后明目張膽地違反它們。

規(guī)避公司的編碼規(guī)則

某些公司有嚴(yán)格的規(guī)定，不允許使用數(shù)字標(biāo)識(shí)符，你必須使用預(yù)先命名的常量。要挫敗這種規(guī)定背后的意圖太容易了。比如，一位聰明的 C 程序員是這么寫(xiě)的：

#define K_ONE 1

#define K_TWO 2?

#define K_THOUSAND 999

編譯器警告

一定要保留一些編譯器警告。在 make 里使用 “-” 前綴強(qiáng)制執(zhí)行，忽視任何編譯器報(bào)告的錯(cuò)誤。這樣，即使維護(hù)代碼的程序員不小心在你的源代碼里造成了一個(gè)語(yǔ)法錯(cuò)誤，make 工具還是會(huì)重新把整個(gè)包build 一遍，甚至可能會(huì)成功！而任何程序員要是手工編譯你的代碼，看到屏幕上冒出一堆其實(shí)無(wú)關(guān)緊要的警告，他們肯定會(huì)覺(jué)得是自己搞壞了代碼。同樣，他們一定會(huì)感謝你讓他們有找錯(cuò)的機(jī)會(huì)。學(xué)有余力的同學(xué)可以做點(diǎn)手腳讓編譯器在打開(kāi)編譯錯(cuò)誤診斷工具時(shí)就沒(méi)法編譯你的程序。當(dāng)然了，編譯器也許能做一些腳本邊界檢查，但是真正的程序員是不用這些特性的，所以你也不該用。既然你用自己的寶貴時(shí)間就能找到這些精巧的bug，何必還多此一舉讓編譯器來(lái)檢查錯(cuò)誤呢？

把 bug 修復(fù)和升級(jí)混在一起

永遠(yuǎn)不要推出什么“bug 修復(fù)"版本。一定要把 bug 修復(fù)和數(shù)據(jù)庫(kù)結(jié)構(gòu)變更、復(fù)雜的用戶(hù)界面修改，還有管理界面重寫(xiě)等混在一起。那樣的話，升級(jí)就變成一件非常困難的事情，人們會(huì)慢慢習(xí)慣 bug 的存在并開(kāi)始稱(chēng)他們?yōu)樘匦?。那些真心希望改變這些”特性“的人們就會(huì)有動(dòng)力升級(jí)到新版本。這樣從長(zhǎng)期來(lái)說(shuō)可以節(jié)省你的維護(hù)工作量，并從你的客戶(hù)那里獲得更多收入。

在你的產(chǎn)品發(fā)布每個(gè)新版本的時(shí)候都改變文件結(jié)構(gòu)

沒(méi)錯(cuò)，你的客戶(hù)會(huì)要求向上兼容，那就去做吧。不過(guò)一定要確保向下是不兼容的。這樣可以阻止客戶(hù)從新版本回退，再配合一套合理的 bug 修復(fù)規(guī)則（見(jiàn)上一條），就可以確保每次新版本發(fā)布后，客戶(hù)都會(huì)留在新版本。學(xué)有余力的話，還可以想辦法讓舊版本壓根無(wú)法識(shí)別新版本產(chǎn)生的文件。那樣的話，老版本系統(tǒng)不但無(wú)法讀取新文件，甚至?xí)裾J(rèn)這些文件是自己的應(yīng)用系統(tǒng)產(chǎn)生的！溫馨提示：PC 上的 Word 文字處理軟件就典型地精于此道。

抵消 Bug

不用費(fèi)勁去代碼里找 bug 的根源。只要在更高級(jí)的例程里加入一些抵銷(xiāo)它的代碼就行了。這是一種很棒的智力測(cè)驗(yàn)，類(lèi)似于玩3D棋，而且能讓將來(lái)的代碼維護(hù)者忙乎很長(zhǎng)時(shí)間都想不明白問(wèn)題到底出在哪里：是產(chǎn)生數(shù)據(jù)的低層例程，還是莫名其妙改了一堆東西的高層代碼。這一招對(duì)天生需要多回合執(zhí)行的編譯器也很好用。你可以在較早的回合完全避免修復(fù)問(wèn)題，讓較晚的回合變得更加復(fù)雜。如果運(yùn)氣好，你永遠(yuǎn)都不用和編譯器前端打交道。學(xué)有余力的話，在后端做點(diǎn)手腳，一旦前端產(chǎn)生的是正確的數(shù)據(jù)，就讓后端報(bào)錯(cuò)。

使用旋轉(zhuǎn)鎖

不要用真正的同步原語(yǔ)，多種多樣的旋轉(zhuǎn)鎖更好 -- 反復(fù)休眠然后測(cè)試一個(gè)(non-volatile的) 全局變量，直到它符合你的條件為止。相比系統(tǒng)對(duì)象，旋轉(zhuǎn)鎖使用簡(jiǎn)便，”通用“性強(qiáng)，”靈活“多變，實(shí)為居家旅行必備。

隨意安插 sync 代碼

把某些系統(tǒng)同步原語(yǔ)安插到一些用不著它們的地方。本人曾經(jīng)在一段不可能會(huì)有第二個(gè)線程的代碼中看到一個(gè)臨界區(qū)（critical section）代碼。本人當(dāng)時(shí)就質(zhì)問(wèn)寫(xiě)這段代碼的程序員，他居然理直氣壯地說(shuō)這么寫(xiě)是為了表明這段代碼是很”關(guān)鍵“（也是critical）的！

優(yōu)雅降級(jí)

如果你的系統(tǒng)包含了一套 NT 設(shè)備驅(qū)動(dòng)，就讓?xiě)?yīng)用程序負(fù)責(zé)給驅(qū)動(dòng)分配 I/O 緩沖區(qū)，然后在任何交易過(guò)程中對(duì)內(nèi)存中的驅(qū)動(dòng)加鎖，并在交易完成后釋放或解鎖。這樣一旦應(yīng)用非正常終止，I/O緩存又沒(méi)有被解鎖，NT服務(wù)器就會(huì)當(dāng)機(jī)。但是在客戶(hù)現(xiàn)場(chǎng)不太可能會(huì)有人知道怎么弄好設(shè)備驅(qū)動(dòng)，所以他們就沒(méi)有選擇（只能請(qǐng)你去免費(fèi)旅游了）。

定制腳本語(yǔ)言

在你的 C/S 應(yīng)用里嵌入一個(gè)在運(yùn)行時(shí)按字節(jié)編譯的腳本命令語(yǔ)言。

依賴(lài)于編譯器的代碼

如果你發(fā)現(xiàn)在你的編譯器或解釋器里有個(gè)bug，一定要確保這個(gè)bug的存在對(duì)于你的代碼正常工作是至關(guān)重要的。畢竟你又不會(huì)使用其他的編譯器，其他任何人也不允許！

一個(gè)貨真價(jià)實(shí)的例子

下面是一位大師編寫(xiě)的真實(shí)例子。讓我們來(lái)瞻仰一下他在這樣短短幾行 C 函數(shù)里展示的高超技巧。

void* Realocate(void*buf, int os, int ns)

{

void*temp;

temp = malloc(os);?

memcpy((void*)temp, (void*)buf, os);?

free(buf);?

buf = malloc(ns);?

memset(buf, 0, ns);?

memcpy((void*)buf, (void*)temp, ns);?

return buf;

}

• 重新發(fā)明了標(biāo)準(zhǔn)庫(kù)里已有的簡(jiǎn)單函數(shù)。
• Realocate?這個(gè)單詞拼寫(xiě)錯(cuò)誤。所以說(shuō)，永遠(yuǎn)不要低估創(chuàng)造性拼寫(xiě)的威力。
• 無(wú)緣無(wú)故地給輸入緩沖區(qū)產(chǎn)生一個(gè)臨時(shí)的副本。
• 無(wú)緣無(wú)故地造型。 memcpy() 里有 (void*)，這樣即使我們的指針已經(jīng)是 (void*) 了也要再造型一次。另外這樣可以傳遞任何東西作為參數(shù)，加10分。
• 永遠(yuǎn)不必費(fèi)力去釋放臨時(shí)內(nèi)存空間。這樣會(huì)導(dǎo)致緩慢的內(nèi)存泄露，一開(kāi)始看不出來(lái)，要程序運(yùn)行一段時(shí)間才行。
• 把用不著的東西也從緩沖區(qū)里拷貝出來(lái)，以防萬(wàn)一。這樣只會(huì)在Unix上產(chǎn)生core dump，Windows 就不會(huì)。
• 很顯然，os 和 ns 的含義分別是”old size" 和 "new size"。
• 給 buf 分配內(nèi)存之后，memset 初始化它為 0。不要使用 calloc()，因?yàn)槟承┤藭?huì)重寫(xiě) ANSI 規(guī)范，這樣將來(lái)保不齊 calloc() 往 buf 里填的就不是 0 了。（雖然我們復(fù)制過(guò)去的數(shù)據(jù)量和 buf 的大小是一樣的，不需要初始化，不過(guò)這也無(wú)所謂啦）

如何修復(fù) "unused variable" 錯(cuò)誤

如果你的編譯器冒出了 "unused local variable" 警告，不要去掉那個(gè)變量。相反，要找個(gè)聰明的辦法把它用起來(lái)。我最喜歡的方法是：??
i = i;

大小很關(guān)鍵

差點(diǎn)忘了說(shuō)了，函數(shù)是越大越好。跳轉(zhuǎn)和 GOTO 語(yǔ)句越多越好。那樣的話，想做任何修改都需要分析很多場(chǎng)景。這會(huì)讓維護(hù)代碼的程序員陷入千頭萬(wàn)緒之中。如果函數(shù)真的體型龐大的話，對(duì)于維護(hù)代碼的程序員就是哥斯拉怪獸了，它會(huì)在他搞清楚情況之前就殘酷無(wú)情地將他們踩翻在地。

一張圖片頂1000句話，一個(gè)函數(shù)就是1000行

把每個(gè)方法體寫(xiě)的盡可能的長(zhǎng) -- 最好是你寫(xiě)的任何方法或函數(shù)都沒(méi)有少于1000行代碼的，而且里邊深度嵌套，這是必須的。

少個(gè)文件

一定要保證一個(gè)或多個(gè)關(guān)鍵文件是找不到的。利用includes 里邊再 includes 就能做到這一點(diǎn)。例如，在你的 main 模塊里，你寫(xiě)上：

#include <stdcode.h>

Stdcode.h 是有的。但是在 stdcode.h 里，還有個(gè)引用：

#include "a:\\refcode.h"

然后，refcode.h 就沒(méi)地方能找到了。

到處可寫(xiě)，無(wú)處可讀

至少要把一個(gè)變量弄成這樣：到處被設(shè)置，但是幾乎沒(méi)有哪里用到它。不幸的是，現(xiàn)代編譯器通常會(huì)阻止你做相反的事：到處讀，沒(méi)處寫(xiě)。不過(guò)你在C 或 C 里還是可以這樣做的。

原始博文發(fā)布于：?Roedy Green's Mindproducts （http://mindprod.com/unmain.html?）。

轉(zhuǎn)載于:https://www.cnblogs.com/3Tai/p/4126952.html

總結(jié)

以上是生活随笔為你收集整理的如何编写无法维护的代码 让自己稳拿铁饭碗 ;-)的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。