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