軟件開發(fā)的22條黃金法則
這個世界需要的不是英雄，是專家 —— 杰洛特《巫師》
編程本質(zhì)上是一門手藝活，既然是手藝，里面就會有很多個人技巧和經(jīng)驗。
“破窗理論”，DRY（Don't repeat yourself），曳光彈，正交性，這些詞的意思是什么你還記得么？
《程序員修煉之道》這本書在我看來就是一本師傅寫給徒弟的開發(fā)哲學(xué)指南。
里面既講了一些軟件開發(fā)的哲學(xué)，比如破窗理論，它解釋了你的代碼為什么很快就會變成“屎山”。也講了一些有用的技巧和工具，比如如何利用好shell，提升你的編程效率。
這本書沒有復(fù)雜的代碼，沒有晦澀難懂的原理，你完全可以當(dāng)作一本閑書來看。
這本書里提到的看似人人都懂的道理，恰恰是很多碼農(nóng)們平常工作中最不重視，卻應(yīng)該去遵守的理念。
我提煉了一些書中我覺得至今仍然沒有過時的觀點（畢竟本書有一定的年頭了，讀起來很有年代感），和大家分享下，這中間也夾雜著一些我的看法和思考。
一、開發(fā)的哲學(xué)
作為開發(fā)，你需要對自己說的話負(fù)責(zé)。對于不可能做到，風(fēng)險太大的事情，你有權(quán)不去為之負(fù)責(zé)。
不要給做不到找借口，在你說做不到的時候，要提供你的想法，告訴大家，做不到的原因是需要重構(gòu)，還是需要時間做原型，還是需要額外的資源支持。
破窗理論：一扇破窗戶，只要有那么一段時間不修理，就會漸漸給建筑的居民帶來廢棄感。于是窗戶就會一個個破碎，人們開始亂丟垃圾，亂涂亂畫。所以不要容忍你的代碼有“破窗戶”。
這一點大家肯定也深有感觸，在你寫代碼的項目里一旦看到了一些亂七八糟的結(jié)構(gòu)和設(shè)計，你也會不自覺地開始往上面寫湊活的代碼，慢慢就變成屎山了。
溫水煮青蛙，代碼是會慢慢腐爛而不被察覺的。要持續(xù)不斷的觀察你項目的變化，而不要只是專注于自己的那一塊代碼。
重視你的”知識“，這是你的資產(chǎn)。既然是資產(chǎn)，就要定期投資（不斷學(xué)習(xí)），多元化地學(xué)習(xí)。并且要定期的評估你的技術(shù)方向，畢竟開發(fā)是個動蕩的行業(yè)，現(xiàn)在吃香的技術(shù)過幾年就會過時。要不斷地調(diào)整你的方向。
在做需求時，要像用戶一樣去思考需求的合理性，而不是一味完成產(chǎn)品下發(fā)的需求。
做的軟件，要溫和的超出用戶的期望。給他們的東西要比他們的期望多一點，給系統(tǒng)增加特性時，多做一些額外的努力，可以給你帶來很大的美譽。
當(dāng)你在的開發(fā)團隊人員龐大時，可以指定每個人負(fù)責(zé)工作的各個方面。圍繞功能，而不是工作職務(wù)進(jìn)行工作的分配。比如有人要討論日期處理，就去找Mary，有人要討論數(shù)據(jù)存儲，就去找Fred。
二、開發(fā)的準(zhǔn)則
不要重復(fù)你自己：DRY（Don't repeat yourself）系統(tǒng)中的每一個組件都要單一，沒有歧義，并且權(quán)威的表示出來。
保持項目的系統(tǒng)正交性：不要讓系統(tǒng)間互相耦合，非正交的系統(tǒng)意味著你修改這邊的系統(tǒng)，會影響到其他的系統(tǒng)。
非正交的一個典型體現(xiàn)是前端的CSS，網(wǎng)上有很多調(diào)侃CSS的段子，CSS的一個修改經(jīng)常會影響到別的地方，這也是CSS很讓人痛苦的一個地方。在后端開發(fā)里，我們要盡量讓系統(tǒng)間不要相互影響，這對系統(tǒng)的傷害是很大的，并且在排查問題時非常痛苦。
保證代碼設(shè)計的可撤銷性：如果你的想法是這個問題的唯一解，那么這會是一個很危險的事情。用戶的需求變化的很快，你的決策很可能只在當(dāng)下是正確的，不存在最終的決策，或者說，時刻要注意和反思，如果現(xiàn)在這個方法行不通，是不是就沒法挽回了。
做好資源的估算：這里的資源指的是很多代碼相關(guān)的資源，比如數(shù)據(jù)庫，存儲，性能等。在開發(fā)前，一定要做好估算，在設(shè)計良好的代碼結(jié)構(gòu)，保證再未來能夠應(yīng)付變化。
把文檔盡量多的做在代碼里，而不是游離于代碼之外。否則，過了一段時間后，你這些文檔就沒有什么作用了。
你不可能寫出完美的軟件：作為一個開發(fā)，你要有這種自覺，自己也不要相信。所以要對自己可能犯的錯誤，做防御性的編程。
異常處理：如果我刪掉所有的異常處理代碼，這些代碼是不是還能運行？如果你的回答是”不能“，那么說明你的異常代碼正在被用在非異常的情形中。這樣不好。
利用好元數(shù)據(jù)：這里的元數(shù)據(jù)可以理解為配置文件。將抽象放進(jìn)代碼，將細(xì)節(jié)放進(jìn)元數(shù)據(jù)。
我們?nèi)粘ｉ_發(fā)中經(jīng)常使用配置文件和分布式配置中心，把能夠放入配置文件的數(shù)據(jù)盡量放入，這樣不僅方便維護和修改，也能夠?qū)崿F(xiàn)不重啟應(yīng)用修改應(yīng)用行為的功能。代碼中應(yīng)該只有我們對業(yè)務(wù)的抽象。
考慮好系統(tǒng)并發(fā)：要為并發(fā)做好周全的考慮。
這個要求是不是看起來很稀松平常，大家都會？其實很多大型系統(tǒng)，尤其是老的系統(tǒng)，都沒有考慮并發(fā)問題（去問問傳統(tǒng)軟件企業(yè)做的軟件，你就知道了）。并發(fā)其實可以算作是互聯(lián)網(wǎng)公司最常遇到的問題，也是各種技術(shù)面試會問的很深的問題，要好好掌握。
不要靠巧合編程，要弄清楚程序為何能夠運行。
我們接觸變成初期，經(jīng)常會有些代碼調(diào)著調(diào)著就跑通了，但是連自己也不知道為什么。這種代碼真正用于線上風(fēng)險很大。畢竟，他也許不是真的能工作，他也許只是看起來能工作！
什么時候該重構(gòu)：當(dāng)你發(fā)現(xiàn)這四個事情出現(xiàn)的時候，就是你該重構(gòu)的時候。
代碼違反了DRY法則 有非正交的設(shè)計 需求變化后代碼過時了 性能有很大問題
重構(gòu)時的準(zhǔn)則：
不要試圖在重構(gòu)的時候同時增加功能。 在開始重構(gòu)前，確保你擁有良好的測試，這樣你才敢放開手腳改動。 采取短小，深思熟慮的步驟。
在測試的時候，要去做狀態(tài)覆蓋，而不是追求代碼覆蓋率。
好好學(xué)習(xí)shell：通常我們喜歡用各種帶界面的軟件，他們的特點是所見即所得。但是也帶來了缺點，所見即全部所得（what you see is all you see）。這對于效率的提升是一個瓶頸，有很多GUI上面需要很多操作的事情，在shell上只需要一行代碼。所以盡管它有點難入門，但是學(xué)好了，會大幅度提高效率。
關(guān)注我
我是一名奮斗在互聯(lián)網(wǎng)一線的后端開發(fā)工程師。
原創(chuàng)文章主要內(nèi)容：
開發(fā)實戰(zhàn) 技術(shù)面試 算法題解/數(shù)據(jù)結(jié)構(gòu)/設(shè)計模式 程序人生
如果文章對你有幫助，請各位同學(xué) 點贊 轉(zhuǎn)發(fā) 收藏 三連，你的支持是對我莫大的鼓勵~