每一個程序員都該知道的10大編程格言

每一個程序員都該知道的10大編程格言（Kevin Pang）：

• 編程格言1：無風不起浪 (There is no smoke without fire）

• 編程格言2：預防爲主，治療爲輔(An ounce of prevention is worth a pound of cure：）

• 編程格言3：不要把雞蛋都放在一個籃子(Don't put all your eggs in one basket) 

• 編程格言4：種瓜得瓜,種豆得豆（As you sow,so shoul you reap）

• 編程格言5：欲速則不達（Great haste makes great waste）

• 編程格言6：三思然後行( Look before you leap。Think first, Program later)

• 編程格言7：當你僅有的一把工具是錘子，全部的東西看起來都像是釘子（When the only tool you have is a hammer, everything looks like a nail）
  

• 編程格言8：沉默就是贊同 （Silence is construed as approval）

• 編程格言9：雙鳥在林不如一鳥在手（A bird in the hand is worth two in the bush）
  

• 編程格言10：能力越大責任越大（With great power comes great responsibility）

1.無風不起浪(There is no smoke without fire)：

設計糟糕的代碼一般表現如下 的一些現象：

•  巨大的類或者方法

• 大區塊註釋的代碼

• 重複的邏輯

• 過多 if/else 層次嵌套

2. 預防爲主，治療爲輔(An ounce of prevention is worth a pound of cure）磨刀不誤砍柴工

    程序員常常錯誤地認爲高效率編碼就是快速編碼，不少程序員不經思索和設計就直接編寫代碼。很不幸地是，這種 Leeroy Jenkins魯莽作法將會編寫出槽糕的代碼，結果致使須要不斷維護和修改代碼，甚至有可能這些槽糕的代碼將會被替換掉。所以，編碼效率不只以編碼的時間，並且還有調試代碼的時間。

撿了芝麻丟了西瓜。磨刀不誤砍柴工。

3. 不要把全部雞蛋放在一個籃子 （Don't put all your eggs in one basket)不要過分依賴某我的

一個軟件項目開發團隊的公共要素（bus factor）是指那些會影響整個項目進程的核心開發人員的總數。好比某人被車撞了或某人生孩子或某人跳槽了，項目可能就會無序，甚至會擱置。
換言之，若是團隊的關鍵成員忽然流失，項目將會怎麼辦？業務仍繼續仍是中止呢？

所以咱們在項目開發中， 每位開發人員最好能最熟悉軟件系統非本身所擅長的部分。

4.種瓜得瓜，種豆得豆 （As you sow, so shall you reap)

《注重實效的程序員》一書中有這樣一段話解釋「破窗理論」：

不要留着「破窗戶」（不良的設計、錯誤的決策或者糟糕的代碼）不修。發現一個就修一個。若是沒有足夠的時間進行適當的修復，就先把它保留起來。或許你可 以把出問題的代碼放到註釋中，或是顯示「未實現」消息，或用虛擬數據加以替代。採起一些措施，防止進一步的惡化。這代表局勢尚在掌控之中。

咱們見過整潔良好的系統在出現「破窗」以後立馬崩潰。雖然促使軟件崩潰的緣由還有其餘因素（咱們將在其餘地方接觸到），但（對「破窗」）置之不理，確定會更快地加速系統崩潰。

簡而言之，好的代碼會促生好的代碼，糟糕的代碼也會促生糟糕的代碼。別低估了習慣的力量。沒人想去整理糟糕的代碼，一樣沒人想把完美的代碼弄得一團糟。寫好你的代碼，它才更可能經得住時間的考驗。

5 .欲速則不達（Great haste makes great waste)

經理、客戶和程序員正日益變得急躁。一切都須要作的事，都須要立刻就作好。正因如此，快速修復問題變得很是急迫。

沒時間對一個新功能進行適當的單元測試？好吧，你能夠先完成一次測試運行，而後你就能夠隨時回來繼續測試它。

當訪問Y屬性時，會不會碰到奇怪的對象引用錯誤？不管怎樣，把代碼放到try/catch語句塊中。咱們要釣到大魚啦！

是否是似曾相識呢？這是由於咱們在之前已經都作到了。而且在某些狀況下、它是無可非議的。畢竟，咱們有最後期限，還得知足客戶和經理。但不要過於頻繁操 做，不然你會發現你的代碼不穩定，有不少熱修復、邏輯重複、未測試的方案和錯誤處理。最後，你要麼是把事情草草作完，要麼是把事情好好作完。

6. 三思然後行（ Look before you leap)

「敏捷開發」這個詞最近被頻繁濫用，常常被程序員用來掩飾他們在軟件開發過程當中的糟糕規劃/設計階段。咱們是設計者，看到產品朝正當方向有實質進展，咱們理應高興。但意外的是，UML圖和用例分析彷佛並不能知足咱們的願望。因此，在不知本身作什麼的狀況下或者不知本身身處何處時，咱們開發人員常常就稀裏糊塗地寫代碼了。

這就比如你要去吃飯，但你根本沒有想好去哪裏吃。由於你太餓了，因此你火燒眉毛地找個餐館，定個桌位。而後你上車開車後沿途在想（找地方吃飯）。只是，這樣會耗費更多的時間，由於你要過較多的U型彎道，還在餐館前停車，也許最後因等待時間過長而不吃了。確切地說，你最後應該能找到地方吃飯，但你可能 吃的飯並非你想吃的，而且這樣花費的時間，可能比你直接在想去的餐館訂餐所花的時間更長。

7.當你僅有的一把工具是錘子，全部的東西看起來都像是釘子（When the only tool you have is a hammer, everything looks like a nail）

                                              看見了吧？我早就說過動態記錄在這個項目中頗有效
程序員有一種傾向，當一談到他們工具時，其視野就變狹窄了。一旦某種方法在咱們的一個項目上「行得通」，咱們就會在接下來全部的項目上都用到它。學習新東 西彷彿是一種煎熬，有時候甚至會心猿意馬。從始至終都在想「若是我用以前的方法作、這個就不會這麼麻煩了」。必定要摒棄這種想法，按咱們所知道的去作，即便那不是最完美的解決方法。
堅持本身所知很簡單，不過從長遠的角度講，選擇一個適合這項工做的工具要容易得多。不然，就會與你的職業生涯格格不入。

8. 沉默就是贊同（Silence is construed as approval）

我什麼都沒看見！沒看見！

"破窗理論"與"變成慣性理論"有着宏觀的聯繫。

編程社區就好像一個現實社區。每一個做品都是一個開發者的縮影。糟糕的代碼發佈的越多，就越容易反映現狀。若是你不去努力編寫優秀、整潔和穩定的代碼，那你天天都將和糟糕的代碼相伴了。

一樣地，若是你看到別人寫出了糟糕的代碼，你就要跟這我的提出來。注意，這時候機智就應該用上場了。通常狀況下，程序員都願意認可他們在軟件開發中仍是有不懂的地方，而且會感謝你的好意。互相幫助對你們都有利，而對問題視而不見，只會使問題一直存在。

9.雙鳥在林不如一鳥在手（A bird in the hand is worth two in the bush）

若是能夠討論系統架構和重構，那麼就差找個時間把事情作完。爲了使正常運做的東西更加簡潔而作改動，權衡改動的利弊很重要。固然了，簡潔是一個理想目標， 但總會有能夠經過重構改進的代碼。在編程世界中，爲了代碼不過期，會頻繁簡單改動代碼。但有時候你又必須保證代碼對客戶有價值。那麼，你面臨一個簡單窘 境：你不能一石二鳥。你在重構舊代碼上所發時間越多，你編寫新代碼的時間就越少。在及時改進代碼和維護程序之間，也須要找到平衡點。

10.能力越大責任越大（With great power comes great responsibility）

毫無疑問，軟件已成爲咱們生活中一個既基本又重要的一部分。正因如此，開發優秀軟件格外重要。乒乓球遊戲中的Bug是一回事，航天飛機導向系統或者航空交通管制系統中的Bug是另一回事。Slashdot曾發表一文，講述了單單Google News的一個小失誤使一家公司股票蒸發11.4億美圓。其餘例子參見《軟件Bug引起的十次嚴重後果》。這些例子便說明了咱們正行使着多大的權利。你今天寫的代碼，不管你是否有意，說不定有朝一日在重要的應用程序中派上用場，這想一想都使人懼怕。編寫正確合格的代碼吧！