《架构整洁之道》之两个价值维度

对于每个软件系统，我们都可以通过行为和架构两个维度来体现它的实际价值。软件研发人员应该确保自己的系统在两个维度上的实际价值都能长时间维持在很高的状态。不幸的是，他们往往只关注一个维度，而忽视了另外一个维度。更不幸的是，他们常常关注的还是错误的维度，这导致了系统的价值最终趋降为零。

一、行为价值

软件系统的行为是其最直观的价值维度。程序员的工作就是让机器按照某种指令方式运转，给系统的使用者创造或者提高利润。

程序员们为了达到这个目的，往往需要帮助系统使用者编写一个对系统功能的定义，也就是需求文档。然后，程序员们再把需求文档转化为实际的代码。

当机器出现异常行为时，程序员负责调试，解决这些问题。

大部分程序员认为这就是他们的全部工作。他们的工作是且仅是:按照需求文档编写代码，并且修复任何Bug。这真是打错特错。

二、架构维度

软件系统的第二个价值维度，就体现在软件这个英文单词上:software。”ware”的意思是”产品”，而”soft”得意思，是指软件的灵活性。

软件系统必须保持灵活。软件发明的目的，就是让我们可以以一种灵活的方式来改变机器的工作行为。对机器上那些很难改变的工作行为，我们通常称之为硬件。

为了达到软件的本来目的，软件系统必须够”软”-也就是说，软件应该容易被修改。当需求方改变需求的时候，随之所需的软件变更必须可以简单而方便地实现。变更实施的难度应该和变更的范畴成等比关系，而与变更得具体形状无关。

三、哪个价值维度更重要

那么，究竟是系统行为更重要，还是系统架构的灵活性更重要？哪个价值更大？系统正常工作更重要，还是系统易于修改更重要？

如果这个问题由业务部门来回答，他们通常认为系统正常工作很重要。系统开发人员常常也就跟随采取了这种态度。但是这种态度是错误的。举例说明:

• 如果某程序可以正常工作，但是无法修改，那么当需求变更的时候它就不再能够正常工作了，我们也无法通过修改让它能继续正常工作。因此，这个程序的价值将成为0。
• 如果某程序目前无法正常工作，但是我们很容易地修改它，那么将它改好，并且随着需求变化不停地修改它，都应该是很容易的事。因此，这个程序会持续产生价值。

四、艾森豪威尔矩阵

艾森豪威尔曾说道:
我有两种难题:紧急的和重要的，二紧急的难题永远是不重要的，重要的永远是不紧急的。

软件系统的第一个价值维度:系统行为，是紧急的，但是并不总是特别重要。

软件系统的第二个价值维度:系统行为，是重要的，但是并不总是特别紧急。

当然，我们会有些重要且紧急，也会有一些事情不重要也不紧急。最终我们应将四类事情进行如下排序:

• 重要且紧急
• 重要不紧急
• 不重要但紧急
• 不重要且不紧急

在这里你可以看到，软件的系统架构-那些重要的事情-占据了该列表的前两位，而系统行为-那些紧急的事情-只占据了第一和第三位。

业务部门与研发人员经常犯的共同错误就是将第三优先级的事情提到第一优先级去做。换句话说，他们没有把真正紧急并且重要的功能和紧急但是不重要的功能分开。这个错误导致了重要的事被忽略了，重要的系统架构问题让位给了不重要的系统行为功能。

研发人员还忘了一点，那就是业务部门原本就是没有能力评估架构的重要程度的，因为这本来就是研发人员自己的工作职责，所以平衡系统架构的重要性和功能的紧急程度这件事，是软件研发人员自己的职责。

四、为好的软件架构而持续斗争

为了做好上述职责,软件团队必须做好斗争的准备-或者说”长期抗争”的准备。现状就是这样。软件团队必须从公司长远利益出发与其他部门抗争，这就和管理团队的工作一样。

有成效的软件研发团队会迎难而上，毫不掩饰地与所有其他的系统相关方进行平等的争吵。请记住，作为一名软件开发人员，你也是相关者之一。软件系统的可维护性需要由你来保护，这是你角色的一部分，也是你职责中不可缺少的一部分，公司雇你的很大一部分原因就是需要有人来做这件事。

如果你是软件架构师，那么这项工作就加倍重要了。软件架构师这一职责本身就应更关注系统的整体结构，而不是具体的功能和系统行为的实现。软件架构师必须创建一个可以让功能实现起来更容易、修改起来更简单、扩展起来更轻松的软件架构。

请记住:如果忽视软件架构的价值，系统将会变得越来越难以维护，终会有一天，系统将会变得再也无法修改。如果系统变成这个样子，那么说明软件开发团队没有和需求方做足够抗争，没有完成自己应尽的职责。