程式設計本質上是一門手藝活，既然是手藝，裡面就會有很多個人技巧和經驗。
“破窗理論”，DRY（Don't repeat yourself），曳光彈，正交性，這些詞的意思是什麼你還記得麼？
《程式設計師修煉之道》這本書在我看來就是一本師傅寫給徒弟的開發哲學指南。
裡面既講了一些軟體開發的哲學，比如破窗理論，它解釋了你的程式碼為什麼很快就會變成“屎山”。也講了一些有用的技巧和工具，比如如何利用好shell，提升你的程式設計效率。
這本書沒有複雜的程式碼，沒有晦澀難懂的原理，你完全可以當作一本閒書來看。
這本書裡提到的看似人人都懂的道理，恰恰是很多碼農們平常工作中最不重視，卻應該去遵守的理念。
我提煉了一些書中我覺得至今仍然沒有過時的觀點（畢竟本書有一定的年頭了，讀起來很有年代感），和大家分享下，這中間也夾雜著一些我的看法和思考。
一、開發的哲學
-
作為開發，你需要對自己說的話負責。對於不可能做到，風險太大的事情，你有權不去為之負責。
-
不要給做不到找藉口，在你說做不到的時候，要提供你的想法，告訴大家，做不到的原因是需要重構，還是需要時間做原型，還是需要額外的資源支援。
-
破窗理論：一扇破窗戶，只要有那麼一段時間不修理，就會漸漸給建築的居民帶來廢棄感。於是窗戶就會一個個破碎，人們開始亂丟垃圾，亂塗亂畫。所以不要容忍你的程式碼有“破窗戶”。
這一點大家肯定也深有感觸，在你寫程式碼的專案裡一旦看到了一些亂七八糟的結構和設計，你也會不自覺地開始往上面寫湊活的程式碼，慢慢就變成屎山了。
-
溫水煮青蛙，程式碼是會慢慢腐爛而不被察覺的。要持續不斷的觀察你專案的變化，而不要只是專注於自己的那一塊程式碼。
-
重視你的”知識“，這是你的資產。既然是資產，就要定期投資（不斷學習），多元化地學習。並且要定期的評估你的技術方向，畢竟開發是個動盪的行業，現在吃香的技術過幾年就會過時。要不斷地調整你的方向。
-
在做需求時，要像使用者一樣去思考需求的合理性，而不是一味完成產品下發的需求。
-
做的軟體，要溫和的超出使用者的期望。給他們的東西要比他們的期望多一點，給系統增加特性時，多做一些額外的努力，可以給你帶來很大的美譽。
-
當你在的開發團隊人員龐大時，可以指定每個人負責工作的各個方面。圍繞功能，而不是工作職務進行工作的分配。比如有人要討論日期處理，就去找Mary，有人要討論資料儲存，就去找Fred。
二、開發的準則
-
不要重複你自己：DRY（Don't repeat yourself）系統中的每一個元件都要單一，沒有歧義，並且權威的表示出來。
-
保持專案的系統正交性：不要讓系統間互相耦合，非正交的系統意味著你修改這邊的系統，會影響到其他的系統。
非正交的一個典型體現是前端的CSS，網上有很多調侃CSS的段子，CSS的一個修改經常會影響到別的地方，這也是CSS很讓人痛苦的一個地方。在後端開發裡，我們要儘量讓系統間不要相互影響，這對系統的傷害是很大的，並且在排查問題時非常痛苦。
-
保證程式碼設計的可撤銷性：如果你的想法是這個問題的唯一解，那麼這會是一個很危險的事情。使用者的需求變化的很快，你的決策很可能只在當下是正確的，不存在最終的決策，或者說，時刻要注意和反思，如果現在這個方法行不通，是不是就沒法挽回了。
-
做好資源的估算：這裡的資源指的是很多程式碼相關的資源，比如資料庫，儲存，效能等。在開發前，一定要做好估算，在設計良好的程式碼結構，保證再未來能夠應付變化。
-
把文件儘量多的做在程式碼裡，而不是遊離於程式碼之外。否則，過了一段時間後，你這些文件就沒有什麼作用了。
-
你不可能寫出完美的軟體：作為一個開發，你要有這種自覺，自己也不要相信。所以要對自己可能犯的錯誤，做防禦性的程式設計。
-
異常處理：如果我刪掉所有的異常處理程式碼，這些程式碼是不是還能執行？如果你的回答是”不能“，那麼說明你的異常程式碼正在被用在非異常的情形中。這樣不好。
-
利用好後設資料：這裡的後設資料可以理解為配置檔案。將抽象放進程式碼，將細節放進後設資料。
我們日常開發中經常使用配置檔案和分散式配置中心，把能夠放入配置檔案的資料儘量放入，這樣不僅方便維護和修改，也能夠實現不重啟應用修改應用行為的功能。程式碼中應該只有我們對業務的抽象。
- 考慮好系統併發：要為併發做好周全的考慮。
這個要求是不是看起來很稀鬆平常，大家都會？其實很多大型系統，尤其是老的系統，都沒有考慮併發問題（去問問傳統軟體企業做的軟體，你就知道了）。併發其實可以算作是網際網路公司最常遇到的問題，也是各種技術面試會問的很深的問題，要好好掌握。
- 不要靠巧合程式設計，要弄清楚程式為何能夠執行。
我們接觸變成初期，經常會有些程式碼調著調著就跑通了，但是連自己也不知道為什麼。這種程式碼真正用於線上風險很大。畢竟，他也許不是真的能工作，他也許只是看起來能工作！
- 什麼時候該重構：當你發現這四個事情出現的時候，就是你該重構的時候。
- 程式碼違反了DRY法則
- 有非正交的設計
- 需求變化後程式碼過時了
- 效能有很大問題
- 重構時的準則：
- 不要試圖在重構的時候同時增加功能。
- 在開始重構前，確保你擁有良好的測試，這樣你才敢放開手腳改動。
- 採取短小，深思熟慮的步驟。
-
在測試的時候，要去做狀態覆蓋，而不是追求程式碼覆蓋率。
-
好好學習shell：通常我們喜歡用各種帶介面的軟體，他們的特點是所見即所得。但是也帶來了缺點，所見即全部所得（what you see is all you see）。這對於效率的提升是一個瓶頸，有很多GUI上面需要很多操作的事情，在shell上只需要一行程式碼。所以儘管它有點難入門，但是學好了，會大幅度提高效率。
關注我
我是一名奮鬥在網際網路一線的後端開發工程師。
平時主要關注後端開發，資料安全，歡迎交流。
- 微信公眾號：後端技術漫談
- Github：@qqxx6661
- CSDN：@蠻三刀把刀
- 知乎：@後端技術漫談
- 掘金：@蠻三刀把刀
- 騰訊雲+社群：@後端技術漫談
- 部落格園：@後端技術漫談
- BiliBili：@蠻三刀把刀
原創文章主要內容：
- 開發實戰
- 技術面試
- 演算法題解/資料結構/設計模式
- 程式人生
個人公眾號：後端技術漫談
如果文章對你有幫助，請各位同學 點贊 轉發 收藏 三連，你的支援是對我莫大的鼓勵~