編程本質上是一門手藝活，既然是手藝，裏面就會有很多個人技巧和經驗。
“破窗理論”，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上只需要一行代碼。所以儘管它有點難入門，但是學好了，會大幅度提高效率。
有道無術，術可成；有術無道，止於術
歡迎大家關注Java之道公衆號
好文章，我在看❤️
本文分享自微信公衆號 - Hollis（hollischuang）。
如有侵權，請聯繫 [email protected] 刪除。
本文參與“OSC源創計劃”，歡迎正在閱讀的你也加入，一起分享。