結合本身經歷聊聊注重實效的程序員應該掌握的幾個原則

本篇文章是《程序員修煉之道》第二章的筆記，總結了高效程序員須要遵照的一些原則和經常使用的開發模式，對咱們有很是重要的指導意義。建議每一個程序員都應該學習並掌握這些原則。若是你們以爲這個系列文章有價值，咱們能夠組織一次抽書的活動，鼓勵你們從原文學習。

DRY 原則

軟件開發過程無時無刻都伴隨着維護，若是項目中有大量的重複代碼會對咱們的維護工做形成很大的麻煩。好比：一段代碼在多個地方出現， 一旦要修改就須要咱們同時修改多個地方，若是某個地方忘記修改就可能致使一些沒必要要的錯誤。所以做者提出 DRY原則 - Don't repeat yourself（不要重複你本身）。

咱們平時有很多重複的場景， 同時也有避免重複的解決方法，下面舉幾個例子。

• 代碼與註釋：咱們常常被說教要在代碼里加註釋。但註釋並非越多越好，咱們應該把註釋留給高級的說明，對於比較低級的說明用代碼代替註釋便可。不然，就存在重複的知識，每次修改代碼都要想着修改註釋
• 代碼與文檔：文檔的更新是永遠滯後於代碼的，常常更新了代碼但忘記更新文檔。咱們能夠採用一些輔助技術或者自研的技術，好比：API doc、Java doc 之類的工具，代碼更新後，文檔會隨着更新
• 設計中的重複：假設某個類中有個起始座標和結束座標兩個屬性，這時再加一個兩點間距離的屬性就有點重複了，由於咱們能夠根據起止點計算出距離
• 臨時性的重複：有時候咱們臨時作一些需求可能用到了項目中某段代碼，咱們通常會直接複製過來用，這時候也存在重複。更完全的作法是咱們能夠把一些比較經常使用的計算邏輯抽象成接口，造成本身的工具包，須要的時候直接引用便可，無需拷貝代碼。好比：一些常見的求和，求最值等須要 for 循環的處理邏輯是否是能夠抽象一個 reduce 函數
• 開發者之間的重複：這個是比較常見的重複，若是一個項目的兩個組同時開發很容易形成同一個小的邏輯在兩個組的成員有各自的實現，這種重複不太好避免。但咱們能夠增長團隊之間的交流，能夠組織一個平臺，把一些比較好的組件開放出來。我作數據開發時常常會用到一些 udf 處理數據，若是我當前項目中沒有，我會到公司的公共平臺去搜相應的關鍵詞， 通常都能找到現成的 udf。我比較建議團隊內部開源不一樣的項目代碼，固然是不涉及機密代碼的前提。我在開發中常常會問上游同窗數據怎麼處理的，通過了什麼邏輯，這樣作一方面增長溝通成本，二來畢竟耳聽爲虛。因此我就常常反編譯上游的代碼，之後須要看邏輯不須要問別人，直接看代碼節省很是多的時間。固然開源也有個好處是咱們能夠學習別人代碼中優秀的地方。

正交原則

正交性就是不相互依賴性或者解耦性。若是兩個或多個事物中的一個發生變化，不會影響其餘事物，那麼這些事物就是正交的。對應到編程，就是咱們常說的高內聚、低耦合。正交的系統好處很是多，正交的系統能夠下降風險，當系統中某個組件修改時，只要對外的接口保持不變，該組件就能夠任意修改而整個系統不會受到影響。正交的系統能提升生產率，由於系統組件是解耦的，所以各個組件能夠獨立地、並行地進行開發。好比最近幾年比較火的先後端分離技術就是很好的表明，之前後端的同窗常常須要寫一些套頁面的前端代碼，先後端同窗的代碼交織在一塊兒相互依賴。但先後端分離後，只須要把協議肯定好，先後端技術就能夠解耦，開發同窗就能夠並行開發，提升生產率。下面列舉幾種維持正交性的方法

• 設計：設計系統時咱們能夠採用基於組件的分層架構。每層提供一級抽象，每層只是用其下面的層次提供的抽象，層與層之間的協議/接口穩定且可擴展，下層組件的改動對上層透明
• 編碼：爲了讓代碼保持解構，咱們能夠開發 「羞怯」 的代碼，對於不須要開放出來的邏輯，能夠控制其訪問權限，不被其餘組件引用。避免使用全局數據，全局數據涉及多個使用方同時更新，致使組件耦合度較高。避免編寫類似的函數，類似的函數每每有重複的代碼，使得修改代碼要同時更新多處
• 測試：在進行單元測試時，若是某個單元牽扯系統其他很大一部分，說明該單元與系統其餘部分耦合度較大，須要引發開發同窗的重視

可撤銷原則

可撤銷原則是說，當系統中某個部分須要改變時，咱們能不能很好的撤銷已有的代碼，靈活的適應新變化。由於需求無時無刻都在變化，所以可撤銷性就一直存在。舉個栗子：假設咱們開發一個數據庫可視化軟件，最開始的需求是基於 Mysql 的，若是咱們不作分層設計，凡是須要增刪改查的地方咱們直接寫 JDBC 代碼。可是某一天咱們底層數據要支持 MongoDB 怎麼辦，由於咱們的 JDBC 代碼分佈在項目的各個模塊的代碼中，幾乎沒法撤銷，這時候系統只能重寫。若是咱們設計之初將數據訪問層做爲一個組件抽象出來，那麼上層只須要調用抽象出來的接口來操做數據庫。這樣作的好處是當須要支持其餘數據庫時，只須要爲該數據庫編寫支持咱們抽象接口的數據庫訪問代碼便可，所以系統就具有可撤銷性的。其實，咱們在 Web 項目中常用 ORM 框架也是基於可撤銷原則的，ORM 能夠將數據庫表映射成對象，底層的增刪改查對上層透明，因此能夠靈活地調整底層數據庫。

曳光彈與原型

在黑暗中須要打擊軍事目標時一般會使用曳光彈，它在槍與擊中的地方之間留下一條煙火般的蹤影，用來指示彈道和目標，從而協助射手修正彈道。其實，黑暗中的目標就像咱們開發中面對的未知系統。面對未知系統，若是咱們製做大量文檔，逐一列出每項需求，嘗試肯定全部未知因素，就猶如在黑夜中對目標未知預先進行大量計算而後射擊，很顯然這種狀況須要消耗大量計算力而且不必定能擊中目標。而注重實效的程序員每每更喜歡使用曳光彈。曳光彈的核心優點就是反饋是及時的。好比：咱們要開發一個支持多種序列化格式的 RPC 框架，最開始咱們是否是能夠先用簡單的系統默認的序列化方式先將整個系統框架搭建起來，先讓系統可以運行起來。運行後咱們能夠及時地獲得使用方的反饋，修復已有問題、增長多種序列化框架、不斷迭代完善。

介紹完了曳光彈再來講說原型，記得在大學學習《軟件工程》時就接觸了原型開發。原型更像是一個 Demo，不注重代碼的實現，而是可以快速出一個可以與產品肯定需求的東西。好比：咱們須要肯定某個系統的 UI 需求，咱們能夠用最快的開發語言，開發出一個 Demo，它的代碼不須要規範，交互界面也不須要太美觀，由於原型大機率不會在後續實際的項目實現中使用。

接下來簡單總結一下這兩種開發模式的區別。曳光彈強調的是明確需求後，咱們能不能開發出一個麻雀雖小、但五臟俱全的系統來快速得到反饋，從而指導咱們進一步迭代。在曳光彈開發模式下，後續代碼是依賴於初版的代碼。而原型開發更側重明確需求這個階段，快速開發一個 Demo ，目的是爲了可以基於原型肯定系統的需求。這個階段不在意用什麼代碼、不在意系統的完整性、健壯性以及正確性，由於原型代碼基本不會用在真實的系統開發中。

領域語言與估算

這節內容我以爲平時應用很少，理解的不深入，所以就簡單總結。領域語言個人理解就是使用（創造）一門規範的僞代碼，爲何是僞代碼呢？假設咱們與產品溝通需求，咱們可使用文字，但咱們都知道中華文字博大精深，別人表達的意思跟咱們的理解可能不一致，不然的話咱們也不須要這麼苦逼的加班，固然直接用編程語言溝通更不可行。那麼就須要一箇中間層的僞代碼，既能清晰的表達出需求，又能讓產品或者使用不一樣編程語言的程序員都能看懂。

對於估算這一節，做者介紹了一些常見的預估問題（估算項目時間、流量）的一些指導性意見，但感受比較偏理論，實操性不強。但給我印象最深的一句話是：

在咖啡機旁給出的估算將像咖啡同樣回來糾纏你。

也就是說估算不等於不假思索的回答，咱們能夠用 「這個問題我如今答覆不了，我回去想下」 之類的話術先應付一下，後續再詳細地思考。

小結

本章主要介紹了三個原則中，這三個原則若是在開發中加以總結和利用將對咱們高效地開發很是有幫助。DRY 原則避免重複勞動，正交原則避免改動一個組件時牽扯整個系統的維護，可撤銷原則避免更換系統某個組件時致使系統崩潰。最後，介紹了曳光彈和原型開發兩種快速開發模式，尤爲是曳光彈，我比較喜歡用，先小規模、小成本搭建骨架並跑起來，後續再不斷地豐富骨肉，但願以上介紹的內容對你往後開發有幫助。

歡迎關注公衆號「渡碼」，我將分享更多優秀書籍的內容，組織按期抽書活動