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