前言
每一個軟體系統都會為利益相關者提供兩種不同的價值:
- 行為(behavior)
- 關於系統「做什麼」
- 行為是指軟體系統執行的動作或功能。這包括系統如何響應使用者輸入、處理資料、執行計算、與其他系統溝通以及產生輸出等。
- 結構(structure)
- 關於系統「如何組織和構建」
- 結構是指軟體系統的內部組織和設計。這包括系統的架構、模組的劃分、類別和函數的設計、資料儲存和管理方式等。結構確保了系統的可擴展性、可維護性、可測試性和其他非功能性需求。
軟體開發人員有責任確保這些價值都保持在高價值，但通常只會把重點放在其中一個而排除另外一個。更糟的是他們往往只會把重點放在這兩個中價值較小的一個，這導致軟體系統最終變得沒有價值。
行為
軟體的第一個價值就是「行為」。程式設計師是被雇用來設計機器的行為，透過機器的人行為能夠獲得利益或節省資金。透過幫助利益相關制定功能規格(functional specification)或需求文件(requirements document)來做到這一點。
當機器違反這些需求時，程式設計師會透過除錯器(debugger)來解決問題。
許多程式設計師認為這就是他們全部的工作。他們相信他們的工作就是讓機器實作出來需求並修復任何錯誤。但可悲的是，他們是錯誤的。
架構
軟體的第二個價值跟software這個字是有相關的，soft表示軟的、ware表示產品(prodcut)，當我們提到軟體(software)時，代表它可以輕易地修改機器行為的一種方式。而如果機器的行為是難以改變的，我們則稱呼為硬體(hardware)。
為了達到軟體的本來目的，軟體就必須是軟的，也就是說它可以很容易改變。當需求方改變需求時，這個改變應該能簡單地實現。進行這種改變難度應該只與改變的範疇(scope)成正比，而不是跟具體形狀(shape)成正比。
需求變更的範疇(scope)和具體形狀(shape)，是決定軟體變更實施成本高低的關鍵。這也是為什麼第二年的研發成本比第一年高很多，第三年又比第二年更高。
問題的根源當然是系統的架構設計。如果系統的架構設計偏向某種特定的形狀，那麼新的變更就會越來越難以實施。所以好的系統架構應該盡可能做到與 具體形狀(shape) 無關。
更高的價值
功能還是架構更有價值呢? 軟體系統能夠工作比較重要，還是軟體系統更容易變更比較重要?
如果你去詢問業務經理，通常會得到的答案是軟體系統能夠工作比較重要。而開發人員也會經常跟著這種態度和思考下去做。這是錯誤的態度。我們可以用簡單的邏輯以極端的情況來進行驗證。
- 如果您給我一個完美的程式，但不可能修改，那麼當需求改變時，它就不能工作了，而我也將無法使其工作。所以這個程式變得毫無用處。
- 如果您給我的程式不能工作但容易修改，那麼我可以使其工作，並隨著需求的變化而繼續工作。因此，該程式將持續是有用的。
有些系統實際上是不可能改變的，因為改變的成本超過了改變的利益。許多系統在某些功能特性或設置的確如此。
當你詢問業務經理，他們是否想要做點改變，他們會說當然是要的，但你會發現到他們只注意到目前的功能，而不會注意到往後的系統擴充或靈活度，畢竟對業務經理來說他們只關注在產品的「行為」上。而今天當業務經理要求你對一個簡易的功能進行變更時，而你把成本估得非常高時，相信業務經理是憤怒的。
Eisenhower 矩陣
由 Dwight D. Eisenhower 總統提到的重要性與緊急性矩陣(圖 2.1)
💡 我有兩類問題，緊急和重要。緊急的不重要，重要的不緊急。
上述這句話有深的道理。我們用軟體的方式來舉例:
- 軟體的第一個價值「行為」是迫切的，但並不總是特別重要。
- 軟體的第二個價值「架構」是重要的，但從不特別迫切。
當然有些事情既迫切又重要，有些事情不迫切也不重要。最終，我們可以把這四個點排出它的優先順序:
- 迫切且重要
- 不迫切但重要
- 迫切但不重要
- 不迫切也不重要
請注意，軟體的系統架構(重要的事情)位於此列表的前兩位，而系統行為(迫切的事情)只佔據了第一和第三的位置。
業務經理和開發人員經常犯的錯誤就是把位置 3 的項目提升到位置 1。換句話說，他們沒有把那些迫切但不重要的功能從那些真正迫切且重要的功能中分離出來。這個失誤會導致忽略了系統架構的重要性，而去重視系統不重要的功能。
開發人員的困境是業務經理沒有能力去評估架構的重要性。而這就是軟體開發人員該去做的。因此軟體開發團隊有責任主張架構的重要性高於功能的迫切性。
為架構而戰
如果你是一名軟體架構師更應該注重在系統的結構而不是其特性和功能。架構師建立了一個架構，使這些特性和功能非常容易開發且易於修改，這才是架構師的職責。
最後需要記住的是，如果架構是最後才出現的，那麼開發系統將變得更昂貴，因為要去作全面性的修改，將變得幾乎不可能完成的。