北大青鳥通州校區(qū)提供：
1. 無風(fēng)不起浪
代碼設(shè)計(jì)是否糟糕，從某些地方就可以看出來。比如：
a. 超大類或超大函數(shù)
b. 大片被注釋的代碼
c. 邏輯重復(fù)
d. If/else嵌套過深
程序員們通常稱它們作代碼異味(Code Smell)，但是就我個人認(rèn)為“代碼警報”這個名字更為合適一些，因?yàn)樗懈叩木o迫感的含義。根本問題處理不當(dāng)，終將引火燒身。
譯注：Code Smell中文譯名一般為“代碼異味”，或“代碼味道”，它是提示代碼中某個地方存在錯誤的一個暗示，開發(fā)人員可以通過這種smell（異味）在代碼中追捕到問題。
2. 預(yù)防為主，治療為輔
20世紀(jì)80年代，豐田公司的流水作業(yè)線因?yàn)樗谌毕蓊A(yù)防方法上的革新變得出了名的高效。每個發(fā)現(xiàn)自己的部門有問題的成員都有權(quán)暫停生產(chǎn)。這個方法意在寧可發(fā)現(xiàn)問題后馬上暫定生產(chǎn)、解決問題，也不能由其繼續(xù)生產(chǎn)而導(dǎo)致更棘手且更高代價的修復(fù)/更換/召回后的問題。
程序員總會做出生產(chǎn)率就等同于快速編碼的錯誤臆斷。許多程序員都會不假思索地直接著手代碼設(shè)計(jì)�？上�，這種LeeroyJenkins式魯莽的做法多會導(dǎo)致軟件的開發(fā)過程變得很邋遢，拙劣的代碼需要不斷的監(jiān)測和修改——也可能會被徹底地替換。最終，生產(chǎn)率所涉及到的因素就不僅僅是寫代碼所消耗的時間了，還要有調(diào)試的時間。稍不留神就會“撿了芝麻丟了西瓜”。（因小失大。）
譯注：Leeroy Jenkins 行為：WOW游戲中一位玩家不顧大家獨(dú)身一人迎敵，導(dǎo)致滅團(tuán)。
3. 不要孤注一擲 （過度依賴某人）
一個軟件開發(fā)團(tuán)隊(duì)的公共要素（bus factor）是指那些會影響整個項(xiàng)目進(jìn)程的核心開發(fā)人員的總數(shù)。比如某人被車撞了或某人生孩子或某人跳槽了，項(xiàng)目可能就會無序，甚至?xí)䲠R置。
譯注： bus factor 即指公共要素，比喻了開發(fā)過程中的一些共同因素。如果擠上 bus 的 factor 越多，bus 就越不穩(wěn)定，所以要控制好 bus factor ，以免問題發(fā)生。
換句話說，如果你的團(tuán)隊(duì)突然失去了一個主力成員，你會怎么辦？生意依舊進(jìn)行還是戛然而止？
很不幸，大多數(shù)軟件團(tuán)隊(duì)都陷入了后一種情況。這些團(tuán)隊(duì)把他們的開發(fā)人員培養(yǎng)成了只會處理他們自己專業(yè)領(lǐng)域的“領(lǐng)域?qū)＜摇薄Ｆ鸪�，這看起來是一個比較合理的方法。它對汽車制造裝配生產(chǎn)線很適用，但是為什么對軟件開發(fā)團(tuán)隊(duì)就不行呢？畢竟，想讓每個成員都掌握所編程序的細(xì)微差別也不太可能，對吧？
問題是開發(fā)人員不容易輕易替換掉。雖然當(dāng)每位成員都可用時，“抽屜方法”很有效，但如果當(dāng)“領(lǐng)域?qū)＜摇蓖蝗灰蛉耸伦儎印⒓膊』蛲话l(fā)事故而無法工作時，抽屜方法立馬土崩瓦解。所以，軟件團(tuán)隊(duì)有一些看似多余實(shí)則重要的后備力量是至關(guān)重要。代碼復(fù)查、結(jié)對編程和共有代碼可用成功營造一個環(huán)境，在這個環(huán)境中，每位開發(fā)人員至少表面上是熟悉自己非擅長領(lǐng)域之外的系統(tǒng)部分。
4. 種瓜得瓜，種豆得豆
《注重實(shí)效的程序員》一書中有這樣一段話解釋“破窗理論”：不要留著“破窗戶”（低劣的設(shè)計(jì)、錯誤的決策或者糟糕的代碼）不修。發(fā)現(xiàn)一個就修一個。如果沒有足夠的時間進(jìn)行適當(dāng)?shù)男蘩恚拖劝阉Ａ羝饋�。或許你可以把出問題的代碼放到注釋中，或是顯示“未實(shí)現(xiàn)”消息，或用虛擬數(shù)據(jù)加以替代。采取一些措施，防止進(jìn)一步的惡化。這表明局勢尚在掌控之中。
我們見過整潔良好的系統(tǒng)在出現(xiàn)“破窗”之后立馬崩潰。雖然促使軟件崩潰的原因還有其他因素（我們將在其他地方接觸到），但（對“破窗”）置之不理，肯定會更快地加速系統(tǒng)崩潰。
簡而言之，好的代碼會促生好的代碼，糟糕的代碼也會促生糟糕的代碼。別低估了慣性的力量。沒人想去整理糟糕的代碼，同樣沒人想把完美的代碼弄得一團(tuán)糟。寫好你的代碼，它才更可能經(jīng)得住時間的考驗(yàn)。
譯注：《注重實(shí)效的程序員》，作者Andrew Hunt / DavidThomas。該書直擊編程陳地，穿過了軟件開發(fā)中日益增長的規(guī)范和技術(shù)藩籬，對核心過程進(jìn)行了審視――即根據(jù)需求，創(chuàng)建用戶樂于接受的、可工作和易維護(hù)的代碼。本書包含的內(nèi)容從個人責(zé)任到職業(yè)發(fā)展，直至保持代碼靈活和易于改編重用的架構(gòu)技術(shù)。從本書中將學(xué)到防止軟件變質(zhì)、消除復(fù)制知識的陷阱、編寫靈活、動態(tài)和易適應(yīng)的代碼、避免出現(xiàn)相同的設(shè)計(jì)、用契約、斷言和異常對代碼進(jìn)行防護(hù)等內(nèi)容。
譯注：破窗理論（BrokenWindowtheory）：是關(guān)于環(huán)境對人們心理造成暗示性或誘導(dǎo)性影響的一種認(rèn)識�！捌拼靶�(yīng)”理論是指：如果有人打壞了一幢建筑物的窗戶玻璃，而這扇窗戶又得不到及時的維修，別人就可能受到某些暗示性的縱容去打爛更多的窗戶。發(fā)現(xiàn)問題就要及時矯正和補(bǔ)救。
5. 欲速則不達(dá)
經(jīng)理、客戶和程序員正日益變得急躁。一切都需要做的事，都需要馬上就做好。正因如此，快速修復(fù)問題變得非常急迫。
沒時間對一個新功能進(jìn)行適當(dāng)?shù)膯卧獪y試？好吧，你可以先完成一次測試運(yùn)行，然后你就可以隨時回來繼續(xù)測試它。
當(dāng)訪問Y屬性時，會不會碰到奇怪的對象引用錯誤？無論怎樣，把代碼放到try/catch語句塊中。我們要釣到大魚啦！
是不是似曾相識呢？這是因?yàn)槲覀冊谝郧耙呀?jīng)都做到了。并且在某些情況下、它是無可非議的。畢竟，我們有最后期限，還得滿足客戶和經(jīng)理。但不要過于頻繁操作，否則你會發(fā)現(xiàn)你的代碼不穩(wěn)定，有很多熱修復(fù)、邏輯重復(fù)、未測試的方案和錯誤處理。最后，你要么是把事情草草做完，要么是把事情好好做完。
6. 三思而后行
“敏捷開發(fā)”這個詞最近被頻繁濫用，經(jīng)常被程序員用來掩飾他們在軟件開發(fā)過程中的糟糕規(guī)劃/設(shè)計(jì)階段。我們是設(shè)計(jì)者，看到產(chǎn)品朝正當(dāng)方向有實(shí)質(zhì)進(jìn)展，我們理應(yīng)高興。但意外的是，UML圖和用例分析似乎并不能滿足我們的愿望。所以，在不知自己做什么的情況下或者不知自己身處何處時，我們開發(fā)人員經(jīng)常就稀里糊涂地寫代碼了。
這就好比你要去吃飯，但你根本沒有想好去哪里吃。因?yàn)槟闾I了，所以你迫不及待地找個餐館，定個桌位。然后你上車開車后沿途在想（找地方吃飯）。只是，這樣會耗費(fèi)更多的時間，因?yàn)槟阋^較多的U型彎道，還在餐館前停車，也許最后因等待時間過長而不吃了。確切地說，你最后應(yīng)該能找到地方吃飯，但你可能吃的飯并不是你想吃的，并且這樣花費(fèi)的時間，可能比你直接在想去的餐館訂餐所花的時間更長。
7. 如果你惟一的工具是一把錘子，你往往會把一切問題看成釘子
程序員有一種傾向，當(dāng)一談到他們工具時，其視野就變狹窄了。一旦某種方法在我們的一個項(xiàng)目上“行得通”，我們就會在接下來所有的項(xiàng)目上都用到它。學(xué)習(xí)新東西仿佛是一種煎熬，有時候甚至?xí)纳癫欢�。從始至終都在想“如果我用之前的方法做、這個就不會這么麻煩了”。一定要摒棄這種想法，按我們所知道的去做，即使那不是最完美的解決方法。
堅(jiān)持自己所知很簡單，不過從長遠(yuǎn)的角度講，選擇一個適合這項(xiàng)工作的工具要容易得多。否則，就會與你的職業(yè)生涯格格不入。
8. 沉默即贊同
"破窗理論"與"變成慣性理論"有著宏觀的聯(lián)系。
編程社區(qū)就好像一個現(xiàn)實(shí)社區(qū)。每個作品都是一個開發(fā)者的縮影。糟糕的代碼發(fā)布的越多，就越容易反映現(xiàn)狀。如果你不去努力編寫優(yōu)秀、整潔和穩(wěn)定的代碼，那你每天都將和糟糕的代碼相伴了。
同樣地，如果你看到別人寫出了糟糕的代碼，你就要跟這個人提出來。注意，這時候機(jī)智就應(yīng)該用上場了。一般情況下，程序員都愿意承認(rèn)他們在軟件開發(fā)中還是有不懂的地方，并且會感謝你的好意�；ハ鄮椭鷮Υ蠹叶加欣鴮栴}視而不見，只會使問題一直存在。
9. 雙鳥在林，不如一鳥在手
如果可以討論系統(tǒng)架構(gòu)和重構(gòu)，那么就差找個時間把事情做完。為了使正常運(yùn)作的東西更加簡潔而做改動，權(quán)衡改動的利弊很重要。當(dāng)然了，簡潔是一個理想目標(biāo)，但總會有可以通過重構(gòu)改進(jìn)的代碼。在編程世界中，為了代碼不過時，會頻繁簡單改動代碼。但有時候你又必須保證代碼對客戶有價值。那么，你面臨一個簡單窘境：你不能一石二鳥。你在重構(gòu)舊代碼上所花時間越多，你編寫新代碼的時間就越少。在及時改進(jìn)代碼和維護(hù)程序之間，也需要找到平衡點(diǎn)。
10. 能力越大，責(zé)任越大
毫無疑問，軟件已成為我們生活中一個既基本又重要的一部分。正因如此，開發(fā)優(yōu)秀軟件格外重要。乒乓球游戲中的Bug是一回事，航天飛機(jī)導(dǎo)向系統(tǒng)或者航空交通管制系統(tǒng)中的Bug是另外一回事。Slashdot曾發(fā)表一文，講述了單單Google News的一個小失誤使一家公司股票蒸發(fā)11.4億美元。其他例子參見《軟件Bug引發(fā)的十次嚴(yán)重后果》。這些例子便說明了我們正行使著多大的權(quán)利。你今天寫的代碼，無論你是否有意，說不定有朝一日在重要的應(yīng)用程序中派上用場，這想想都令人害怕。編寫正確合格的代碼吧！
譯注：Slashdot是一個資訊科技網(wǎng)站。
