二進制世界建造者 編程格言

1.保持簡單直白(Keep It Simple Stupid)

2.不要自我複製(Don’t Repeat Yourself)

3.能幹的人解決問題。智慧的人繞開問題(A clever person solves a problem. A wise person avoids it)– Einstein

4.沉默會被理解爲贊同(Silence is construed as approval)( Picked from Kevin blog ) 

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

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

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

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

5.沒有火就不會有煙(There is no smoke without fire)

譯註：Code Smell中文譯名通常爲「代碼異味」，或「代碼味道」，它是提示代碼中某個地方存在錯誤的一個暗示，開發人員能夠經過這種smell（異味）在代碼中追捕到問題。

代碼設計是否糟糕，從某些地方就能夠看出來。好比： 

a. 超大類或超大函數 

b. 大片被註釋的代碼 

c. 邏輯重複 

d. If/else嵌套過深  

程序員們一般稱它們做代碼異味(Code Smell)，可是就我我的認爲「代碼警報」這個名字更爲合適一些，由於它有更高的緊迫感的含義。根本問題處理不當，終將引火燒身。  

6.先想好，後編程(Think first, Program later) 

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

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

7.永遠不要假設計算機爲你假設了任何前提(Never assume the computer assumes anything) 

8.Leeroy Jenkins 行爲 

20世紀80年代，豐田公司的流水做業線由於它在缺陷預防方法上的革新變得出了名的高效。每一個發現本身的部門有問題的成員都有權暫停生產。這個方法意在寧肯發現問題後立刻暫定生產、解決問題，也不能由其繼續生產而致使更棘手且更高代價的修復/更換/召回後的問題。 

程序員總會作出生產率就等同於快速編碼的錯誤臆斷。許多程序員都會不假思索地直接着手代碼設計。惋惜，這種Leeroy Jenkins式魯莽的作法多會致使軟件的開發過程變得很邋遢，拙劣的代碼須要不斷的監測和修改——也可能會被完全地替換。最終，生產率所涉及到的因素就 不只僅是寫代碼所消耗的時間了，還要有調試的時間。稍不留神就會「撿了芝麻丟了西瓜」。（因小失大。） 

譯註：Leeroy Jenkins 行爲：WOW遊戲中一位玩家不顧你們獨身一人迎敵，致使滅團。 

9.不要背注一擲 （過分依賴某人） 

一個軟件開發團隊的公共要素（bus factor）是指那些會影響整個項目進程的核心開發人員的總數。好比某人被車撞了或某人生孩子或某人跳槽了，項目可能就會無序，甚至會擱置。 

譯註： bus factor 即指公共要素，比喻了開發過程當中的一些共同因素。若是擠上 bus 的 factor 越多，bus 就越不穩定，因此要控制好 bus factor ，以避免問題發生。 

換句話說，若是你的團隊忽然失去了一個主力成員，你會怎麼辦？生意依舊進行仍是戛然而止？ 

很不幸，大多數軟件團隊都陷入了後一種狀況。這些團隊把他們的開發員培養成了只會處理他們本身專業領域的「領域專家」。起初，這看起來是一個比較合 理的方法。它 對汽車製造裝配生產線很適用，可是爲何對軟件開發團隊就不行呢？畢竟，想讓每一個成員都掌握所編程序的細微差異也不太可能，對吧？ 

問題是開發人員不容易輕易替換掉。雖然當每位成員均可用時，「抽屜方法」頗有效，但若是當「領域專家」忽然因人事變更、疾病或突發事故而沒法工做 時，抽屜 方法立馬土崩瓦解。（因此，）軟件團隊有一些看似多餘實則重要的後備力量是相當重要。代碼複查、結對編程和共有代碼可用成功營造一個環境，在這個環境中， 每位開發人員至少表面上是熟悉本身非擅長領域以外的系統部分。 

10.破窗理論（Broken Window theory） 

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

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

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

譯註：《注重實效的程序員》，做者Andrew Hunt/David Thomas。該書直擊編程陳地，穿過了軟件開發中日益增加的規範和技術藩籬，對核心過程進行了審視――即根據需求，建立用戶樂於接受的、可工做和易維護 的 代碼。本書包含的內容從我的責任到職業發展，直至保持代碼靈活和易於改編重用的架構技術。從本書中將學到防止軟件變質、消除複製知識的陷阱、編寫靈活、動 態和易適應的代碼、避免出現相同的設計、用契約、斷言和異常對代碼進行防禦等內容。 

譯註：破窗理論（Broken Window theory）：是關於環境對人們心理形成暗示性或誘導性影響的一種認識。「破窗效應」理論是指：若是有人打壞了一幢建築物的窗戶玻璃，而這扇窗戶又得不 到及時的維修，別人就可能受到某些暗示性的縱容去打爛更多的窗戶。發現問題就要及時矯正和補救。 

11. 欲速則不達 

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

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

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

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

12. 若是你唯一的工具是一把錘子，你每每會把一切問題當作釘子 

看見了吧？我早就說過動態記錄在這個項目中頗有效 

程序員有一種傾向，當一談到他們工具時，其視野就變狹窄了。一旦某種方法在咱們的一個項目上「行得通」，咱們就會在接下來全部的項目上都用到它。學 習新東 西彷彿是一種煎熬，有時候甚至會心猿意馬。從始至終都在想「若是我用以前的方法作、這個就不會這麼麻煩了」。必定要摒棄這種想法，按咱們所知道的去作，即 使那不是最完美的解決方法。 

堅持本身所知很簡單，不過從長遠的角度講，選擇一個適合這項工做的工具要容易得多。不然，就會與你的職業生涯格格不入。

13. 雙鳥在林，不如一鳥在手 

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

14. 能力越大，責任越大 

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