架構整潔之道筆記（一）概述

架構和設計這兩者有區別嗎？

「架構」這個詞往往使用於「高層級」的討論中，這類討論一般都把「底層」的實現細節排除在外。而「設計」一詞，往往用來指代具體的系統底層組織結構和實現的細節。但是，從乙個真正的系統架構師的日常工作來看，這樣的區分是根本不成立的。

底層設計細節和高層架構資訊是不可分割的，它們組合在一起，共同定義了整個軟體系統，缺一不可。

軟體架構的終極目標是，用最小的人力成本來滿足構建和維護該系統的需求。

乙個軟體架構的優劣，可以用它滿足使用者需求所需要的成本來衡量。如果該成本很低，並且在系統的整個生命週期內一直能維持這樣的低成本，那麼這個系統的設計就是優秀的。如果該系統的每次發布都會提公升下一次變更的成本，那麼這個設計就是不好的。

對於每個軟體系統，我們都可以通過行為和架構兩個維度來體現它的實際價值。

軟體系統的行為是其最直觀的價值維度。大部分程式設計師認為他們的工作是且僅是：按照需求文件編寫**，並且修復任何bug。這真是大錯特錯。

軟體系統的架構是第二個價值維度。軟體應該容易被修改，當需求方改變需求的時候，當需求方改變需求的時候，軟體變更必須可以簡單而方便地實現。

系統行為和系統架構，哪個價值維度更重要？系統正常工作更重要，還是系統易於修改更重要？

業務部門會認為，完成現在的功能比實現未來的靈活度更重要。但諷刺的是，如果事後業務部門提出了一項需求，而你的預估工作量大大超出他們的預期，這幫傢伙通常會對你放任系統混亂到無法變更的狀態而勃然大怒。

軟體系統的第乙個價值維度：系統行為，是緊急的，但是並不總是特別重要。

軟體系統的第二個價值維度：系統架構，是重要的，但是並不總是特別緊急。

優先順序的排序：1.重要且緊急；2.重要不緊急；3.不重要但緊急；4.不重要且不緊急。

業務部門與研發人員經常犯的共同錯誤就是將第三優先順序的事情提到第一優先順序去做。沒有把真正緊急並且重要的功能和緊急但是不重要的功能分開。這個錯誤導致了重要的系統架構問題讓位給了不重要的系統行為功能。

軟體架構師應該更關注系統的整體結構，而不是具體的功能和系統行為的實現。軟體架構師必須建立出乙個可以讓功能實現起來更容易、修改起來更簡單、擴充套件起來更輕鬆的軟體架構。

架構整潔之道筆記（一） 概述