推出你自己的內(nèi)存分配
地球人兒都知道，調(diào)試動(dòng)態(tài)存儲(chǔ)是復(fù)雜和費(fèi)時(shí)的。與其逐個(gè)類去確認(rèn)它沒有內(nèi)存溢出，還不如自創(chuàng)一套存儲(chǔ)分配機(jī)制呢。其實(shí)它無(wú)非是從一大片內(nèi)存中malloc一塊空間而已。用不著釋放內(nèi)存，讓用戶定期重啟動(dòng)系統(tǒng)，這樣不就清除了堆么。重啟之后系統(tǒng)需要追蹤的就那么一點(diǎn)東西，比起解決所有的內(nèi)存泄露簡(jiǎn)單得不知道到哪里去了！而且，只要用戶記得定期重啟系統(tǒng)，他們也永遠(yuǎn)不會(huì)遇到堆空間不足的問(wèn)題。一旦系統(tǒng)被部署，你很難想象他們還能改變這個(gè)策略。
其他雜七雜八的招
如果你給某人一段程序，你會(huì)讓他困惑一天；如果你教他們?nèi)绾尉幊?，你?huì)讓他困惑一輩子。 — Anonymous
不要重編譯
讓我們從一條可能是有史以來(lái)最友好的技巧開始：把代碼編譯成可執(zhí)行文件。如果它能用，就在源代碼里做一兩個(gè)微小的改動(dòng) —每個(gè)模塊都照此辦理。但是不要費(fèi)勁巴拉地再編譯一次了。 你可以留著等以后有空而且需要調(diào)試的時(shí)候再說(shuō)。多年以后，等可憐的維護(hù)代碼的程序員更改了代碼之后發(fā)現(xiàn)出錯(cuò)了，他會(huì)有一種錯(cuò)覺，覺得這些肯定是他自己最近修改的。這樣你就能讓他毫無(wú)頭緒地忙碌很長(zhǎng)時(shí)間。
挫敗調(diào)試工具
對(duì)于試圖用行調(diào)試工具追蹤來(lái)看懂你的代碼的人，簡(jiǎn)單的一招就能讓他狼狽不堪，那就是把每一行代碼都寫得很長(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)迫用戶經(jīng)常升級(jí) —畢竟沒人愿意用一個(gè)過(guò)時(shí)的版本嘛。即便他們覺得他們對(duì)現(xiàn)有的程序滿意了，想想看，如果他們看到你又“完善“了它，他們會(huì)多么開心??！不要告訴任何人版本之間的差別，除非你被逼無(wú)奈— 畢竟，為什么要告訴他們本來(lái)永遠(yuǎn)也不會(huì)注意到的一些bug呢？
“關(guān)于”
”關(guān)于“一欄應(yīng)該只包含程序名、程序員姓名和一份用法律用語(yǔ)寫的版權(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ì)很無(wú)聊。最后，如果你能在用戶不注意的情況下做出這些變更，那就更好了— 這會(huì)讓他們保持警惕，戒驕戒躁。
無(wú)需技能
寫無(wú)法維護(hù)代碼不需要多高的技術(shù)水平。喊破嗓子不如甩開膀子，不管三七二十一開始寫代碼就行了。記住，管理層還在按代碼行數(shù)考核生產(chǎn)率，即使以后這些代碼里的大部分都得刪掉。
只帶一把錘子
一招鮮吃遍天，會(huì)干什么就吆喝什么，輕裝前進(jìn)。如果你手頭只有一把錘子，那么所有的問(wèn)題都是釘子。
規(guī)范體系
有可能的話，忽略當(dāng)前你的項(xiàng)目所用語(yǔ)言和環(huán)境中被普羅大眾所接受的編程規(guī)范。比如，編寫基于MFC 的應(yīng)用時(shí)，就堅(jiān)持使用STL編碼風(fēng)格。
翻轉(zhuǎn)通常的 TrueFalse 慣例
把常用的 true 和 false 的定義反過(guò)來(lái)用。這一招聽起來(lái)平淡無(wú)奇，但是往往收獲奇效。你可以先藏好下面的定義：
1
2
#define TRUE 0
#define FALSE 1
把這個(gè)定義深深地藏在代碼中某個(gè)沒人會(huì)再去看的文件里不易被發(fā)現(xiàn)的地方，然后讓程序做下面這樣的比較
1
2
if ( var == TRUE )
if ( var != FALSE )
某些人肯定會(huì)迫不及待地跳出來(lái)“修正”這種明顯的冗余，并且在其他地方照著常規(guī)去使用變量var：
1
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é)中寫上這些沒用過(guò)的庫(kù)。
不要用庫(kù)
假裝不知道有些庫(kù)已經(jīng)直接在你的開發(fā)工具中引入了。如果你用VC++編程，忽略MFC 或 STL的存在，手工編寫所有字符串和數(shù)組的實(shí)現(xiàn)；這樣有助于保持你玩指針技術(shù)的高水平，并自動(dòng)阻止任何擴(kuò)展代碼功能的企圖。
創(chuàng)建一套Build順序
把這套順序規(guī)則做得非?；逎?，讓維護(hù)者根本無(wú)法編譯任何他的修改代碼。秘密保留 SmartJ ，它會(huì)讓make腳本形同廢物。類似地，偷偷地定義一個(gè) javac類，讓它和編譯程序同名。說(shuō)到大招，那就是編寫和維護(hù)一個(gè)定制的小程序，在程序里找到需要編譯的文件，然后通過(guò)直接調(diào)用sun.tools.javac.Main 編譯類來(lái)進(jìn)行編譯。
Make的更多玩法
用一個(gè) makefile-generated-batch-file批處理文件從多個(gè)目錄復(fù)制源文件，文件之間的覆蓋規(guī)則在文檔中是沒有的。這樣，無(wú)需任何炫酷的源代碼控制系統(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++程序員是這么寫的：
1
2
3
#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ì)覺得是自己搞壞了代碼。同樣，他們一定會(huì)感謝你讓他們有找錯(cuò)的機(jī)會(huì)。學(xué)有余力的同學(xué)可以做點(diǎn)手腳讓編譯器在打開編譯錯(cuò)誤診斷工具時(shí)就沒法編譯你的程序。當(dāng)然了，編譯器也許能做一些腳本邊界檢查，但是真正的程序員是不用這些特性的，所以你也不該用。既然你用自己的寶貴時(shí)間就能找到這些精巧的bug，何必還多此一舉讓編譯器來(lái)檢查錯(cuò)誤呢？
把 bug修復(fù)和升級(jí)混在一起
永遠(yuǎn)不要發(fā)布什么“bug 修復(fù)”版本。一定要把 bug修復(fù)和數(shù)據(jù)庫(kù)結(jié)構(gòu)變更、復(fù)雜的用戶界面修改，還有管理界面重寫等混在一起。那樣的話，升級(jí)就變成一件非常困難的事情，人們會(huì)慢慢習(xí)慣 bug的存在并開始稱他們?yōu)樘匦?。那些真心希望改變這些”特性“的人們就會(huì)有動(dòng)力升級(jí)到新版本。這樣從長(zhǎng)期來(lái)說(shuō)可以節(jié)省你的維護(hù)工作量，并從你的客戶那里獲得更多收入。
在你的產(chǎn)品發(fā)布每個(gè)新版本的時(shí)候都改變文件結(jié)構(gòu)
沒錯(cuò)，你的客戶會(huì)要求向上兼容，那就去做吧。不過(guò)一定要確保向下是不兼容的。這樣可以阻止客戶從新版本回退，再配合一套合理的 bug修復(fù)規(guī)則（見上一條），就可以確保每次新版本發(fā)布后，客戶都會(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í)的例程里加入一些抵銷它的代碼就行了。這是一種很棒的智力測(cè)驗(yàn)，類似于玩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ū)（criticalsection）代碼。本人當(dāng)時(shí)就質(zhì)問(wèn)寫這段代碼的程序員，他居然理直氣壯地說(shuō)這么寫是為了表明這段代碼是很”關(guān)鍵“（單詞也是critical）的！
優(yōu)雅降級(jí)
如果你的系統(tǒng)包含了一套 NT 設(shè)備驅(qū)動(dòng)，就讓應(yīng)用程序負(fù)責(zé)給驅(qū)動(dòng)分配 I/O緩沖區(qū)，然后在任何交易過(guò)程中對(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)旅游了）。
定制腳本語(yǔ)言
在你的 C/S 應(yīng)用里嵌入一個(gè)在運(yùn)行時(shí)按字節(jié)編譯的腳本命令語(yǔ)言。
依賴于編譯器的代碼
如果你發(fā)現(xiàn)在你的編譯器或解釋器里有個(gè)bug，一定要確保這個(gè)bug的存在對(duì)于你的代碼正常工作是至關(guān)重要的。畢竟你又不會(huì)使用其他的編譯器，其他任何人也不允許！
一個(gè)貨真價(jià)實(shí)的例子
下面是一位大師編寫的真實(shí)例子。讓我們來(lái)瞻仰一下他在這樣短短幾行 C 函數(shù)里展示的高超技巧。
1
2
3
4
5
6
7
8
9
10
11
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);
returnbuf;
}
重新發(fā)明了標(biāo)準(zhǔn)庫(kù)里已有的簡(jiǎn)單函數(shù)。
Realocate這個(gè)單詞拼寫錯(cuò)誤。所以說(shuō)，永遠(yuǎn)不要低估創(chuàng)造性拼寫的威力。
無(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)存泄露，一開始看不出來(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ì)重寫 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)。我最喜歡的方法是：
1
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è)方法體寫的盡可能的長(zhǎng) — 最好是你寫的任何一個(gè)方法或函數(shù)都不會(huì)少于1000行代碼，而且里邊是深度嵌套，這是必須的。
少個(gè)文件
一定要保證一個(gè)或多個(gè)關(guān)鍵文件無(wú)法找到。利用includes 里邊再 includes 就能做到這一點(diǎn)。例如，在你的 main模塊里，你寫上：
1
#include
Stdcode.h 是有的。但是在 stdcode.h 里，還有個(gè)引用：
1
#include "a:\\refcode.h"
然后，refcode.h 就沒地方能找到了。
（【譯者注】為啥找不到呢？仔細(xì)看看，現(xiàn)在還有人知道 a:\ 是什么嗎？A盤！傳說(shuō)中的軟盤…）
到處都寫，無(wú)處會(huì)讀
至少要把一個(gè)變量弄成這樣：到處被設(shè)置，但是幾乎沒有哪里用到它。不幸的是，現(xiàn)代編譯器通常會(huì)阻止你做相反的事：到處讀，沒處寫。不過(guò)你在C或 C++ 里還是可以這樣做的。
