《架構整潔之道》之兩個價值維度

對於每個軟體系統，我們都可以通過行為和架構兩個維度來體現它的實際價值。軟體研發人員應該確保自己的系統在兩個維度上的實際價值都能長時間維持在很高的狀態。不幸的是，他們往往只關注乙個維度，而忽視了另外乙個維度。更不幸的是，他們常常關注的還是錯誤的維度，這導致了系統的價值最終趨降為零。

軟體系統的行為是其最直觀的價值維度。程式設計師的工作就是讓機器按照某種指令方式運轉，給系統的使用者創造或者提高利潤。

程式設計師們為了達到這個目的，往往需要幫助系統使用者編寫乙個對系統功能的定義，也就是需求文件。然後，程式設計師們再把需求文件轉化為實際的**。

當機器出現異常行為時，程式設計師負責除錯，解決這些問題。

大部分程式設計師認為這就是他們的全部工作。他們的工作是且僅是:按照需求文件編寫**，並且修復任何bug。這真是打錯特錯。

軟體系統的第二個價值維度，就體現在軟體這個英文單詞上:software。」ware」的意思是」產品」，而」soft」得意思，是指軟體的靈活性。

軟體系統必須保持靈活。軟體發明的目的，就是讓我們可以以一種靈活的方式來改變機器的工作行為。對機器上那些很難改變的工作行為，我們通常稱之為硬體。

為了達到軟體的本來目的，軟體系統必須夠」軟」-也就是說，軟體應該容易被修改。當需求方改變需求的時候，隨之所需的軟體變更必須可以簡單而方便地實現。變更實施的難度應該和變更的範疇成等比關係，而與變更得具體形狀無關。

那麼，究竟是系統行為更重要，還是系統架構的靈活性更重要？哪個價值更大？系統正常工作更重要，還是系統易於修改更重要？

如果這個問題由業務部門來回答，他們通常認為系統正常工作很重要。系統開發人員常常也就跟隨採取了這種態度。但是這種態度是錯誤的。舉例說明:

艾森豪威爾曾說道:

我有兩種難題:緊急的和重要的，二緊急的難題永遠是不重要的，重要的永遠是不緊急的。

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

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

當然，我們會有些重要且緊急，也會有一些事情不重要也不緊急。最終我們應將四類事情進行如下排序:

在這裡你可以看到，軟體的系統架構-那些重要的事情-佔據了該列表的前兩位，而系統行為-那些緊急的事情-只佔據了第一和第三位。

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

研發人員還忘了一點，那就是業務部門原本就是沒有能力評估架構的重要程度的，因為這本來就是研發人員自己的工作職責，所以平衡系統架構的重要性和功能的緊急程度這件事，是軟體研發人員自己的職責。

為了做好上述職責,軟體團隊必須做好鬥爭的準備-或者說」長期抗爭」的準備。現狀就是這樣。軟體團隊必須從公司長遠利益出發與其他部門抗爭，這就和管理團隊的工作一樣。

有成效的軟體研發團隊會迎難而上，毫不掩飾地與所有其他的系統相關方進行平等的爭吵。請記住，作為一名軟體開發人員，你也是相關者之一。軟體系統的可維護性需要由你來保護，這是你角色的一部分，也是你職責中不可缺少的一部分，公司僱你的很大一部分原因就是需要有人來做這件事。

如果你是軟體架構師，那麼這項工作就加倍重要了。軟體架構師這一職責本身就應更關注系統的整體結構，而不是具體的功能和系統行為的實現。軟體架構師必須建立乙個可以讓功能實現起來更容易、修改起來更簡單、擴充套件起來更輕鬆的軟體架構。

請記住:如果忽視軟體架構的價值，系統將會變得越來越難以維護，終會有一天，系統將會變得再也無法修改。如果系統變成這個樣子，那麼說明軟體開發團隊沒有和需求方做足夠抗爭，沒有完成自己應盡的職責。