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

其他雜七雜八的招

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

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

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

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

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

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

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

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

只帶一把錘子
一招鮮吃遍天,，會(huì)干什么就吆喝什么，輕裝前進(jìn),。如果你手頭只有一把錘子,，那么所有的問題都是釘子。

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

翻轉(zhuǎn)通常的 True False 慣例
把常用的 true 和 false 的定義反過來用,。這一招聽起來平淡無奇，但是往往收獲奇效,。你可以先藏好下面的定義：

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

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

還有一招是為 TRUE 和 FALSE賦予相同的值,，雖然大部分人可能會(huì)看穿這種騙局,。給它們分別賦值 1 和 2 或者 -1 和 0 是讓他們瞎忙乎的方式里更精巧的,，而且這樣做看起來也不失對(duì)他們的尊重,。你在Java 里也可以用這一招，定義一個(gè)叫 TRUE 的靜態(tài)常量,。在這種情況下,，其他程序員更有可能懷疑你干的不是好事，因?yàn)镴ava里已經(jīng)有了內(nèi)建的標(biāo)識(shí)符 true,。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

一個(gè)貨真價(jià)實(shí)的例子
下面是一位大師編寫的真實(shí)例子,。讓我們來瞻仰一下他在這樣短短幾行 C 函數(shù)里展示的高超技巧,。

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

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

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

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

一張圖片頂1000句話,，一個(gè)函數(shù)就是1000行
把每個(gè)方法體寫的盡可能的長(zhǎng) — 最好是你寫的任何一個(gè)方法或函數(shù)都不會(huì)少于1000行代碼，而且里邊是深度嵌套,，這是必須的,。

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

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

然后，refcode.h 就沒地方能找到了,。

（【譯者注】為啥找不到呢,？仔細(xì)看看，現(xiàn)在還有人知道 a:\ 是什么嗎？A盤,！傳說中的軟盤…）

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