今天睡覺前簡單扯兩句，說一個大家容易忽略的問題。
在我們日常的工作中，項目中的代碼寫到一定程度，常見結構性邏輯都熟悉之後，生產代碼的書寫變得越來越不重要，難點一個是設計，另一個是可測試性。
程序設計一般遵循層次原則，一般說來，上層的程序可以調用下層的程序，同層之間也可能存在互相的調用。上層和下面各個層次之間的調用是單方向的，上層代碼調用業務代碼得到返回值，業務代碼只能通過消息、事件和拋出錯誤等方式與上層代碼發生聯繫，不能夠在下層service代碼中直接調用上層控制層的代碼，否則業務代碼將不可測試。
比如對象A依賴對象B裏的C方法，而C方法會從數據庫裏讀取數據。那麼A 就不要直接依賴B的實體類，而引用B的接口。當我們對A編寫單元測試時，只要注入B的mock實現即可。同理，方法中含有service調用時，不要直接依賴service調用，而是依賴函數接口，在函數接口中傳遞 service 調用，如上面的做法。這樣，編寫單元測試時，只要傳入lambda 表達式返回mock數據即可。
這個例子說明可測試性對於設計的意義。有的設計易於測試或驗證，另外一些可能是正確的，或者直覺上實現更簡單，但是它們難以測試或驗證，這個時候可測試性要求就是選擇設計的依據了。
最後總結一下，設計、代碼實現和測試本質上是一體的，不能割裂，不關注測試的架構師或者開發同學經常會把測試同學搞得沒法工作，或者容忍測試低效質量低下。設計不具有良好的可測試性是在構建項目最初就埋下的對工程質量影響最大的雷，設計不改可能後面撲多少人多少時間上去都沒法保證質量了，形成工程成本上的黑洞。
描二維碼或手動搜索微信公衆號【架構棧】：ForestNotes
歡迎轉載，帶上以下二維碼即可
點擊“閱讀原文”，所有【架構棧】近期的架構文章彙總
↓↓↓