第二章 两个值的故事
每个软件系统都提供两个不同值给利益相关者：行为和结构。开发者为保证这两个值都维持高水平负责。他们经常会重视一个而忽略另一个，甚至，他们常常很少关注这两个值，最后软件系统毫无价值。
行为
软件的第一个值是行为。程序员被雇佣来使机器表现某种行为为利益相关者赚钱或节约钱。他们通过开发某种功能或需求文档，然后编写代码，使得利益相关者的机器可以满足这些条件。
当机器违反了这些需求，程序员开始用debugger，解决问题。
很多程序员相信这就是他们工作的全部。他们相信他们的工作是让机器实现需求和修复bugs，那他们真是深深的误解了。
架构
软件的第二个值得从“软件”这个词讲起，即“软”和“件”的组合。“件”意味着“生产”，“软”这个词，呃，就是第二个值的意义所在。
发明的软件是“软”的。它旨在成为轻松改变机器行为的一种方式。 如果我们希望机器的行为难以改变，我们可以称之为硬件。
为了满足这个目的，软件必须得“软”，也就是容易改变。当利益相关者改变他们关于特性的想法，那实现这种改变得简单容易。进行这种改变的难度应该只与改变的范围成正比，而不是与改变的形状成正比。
正是这种范围和形状的差异经常促使软件开发成本的增长。这就是成本与所要求的变化规模不成比例的原因。这是开发第一年比第二年便宜得多，第二年又比第三年便宜得多的原因。
从利益相关者的角度来看，他们只是提供了一个大致相似范围的变化。从开发者的角度来看，利益相关者正在给他们一些拼图游戏，他们必须适应不断增加的复杂性。每个新的请求都比上一个难以适应，因为系统的形状与请求的形状不匹配。
我在这里以非常规的方式使用“形状”这个词，但是我认为这个比喻是恰当的。好像软件开发人员常常觉得自己被迫将方钉塞入圆孔中。
这个问题当然是系统的架构。这种架构越喜欢一种形状而不是另一种形状，新的特征就可能难以适应该结构。因此体系结构应该是形状无关的，才是实用的。
更大的值
功能和架构？两者那个是更大的值？那个值于软件系统运作会更重要？那个值对于使得软件系统容易改变会更重要？
如果你问业务经理，他们经常会说软件系统能工作更重要。反过来，开发者也会经常跟着这种态度去做。但是这是错误的态度。我可以用极端的简单逻辑工具来证明这是错误的。
- 如果您给我一个运行完美的程序，但不可能改变，那么当需求改变时，它将没法用了，我将无法使其工作。所以这个程序将变得毫无用处。
- 如果你给我的程序没法用，但很容易改变，那么我可以使它工作，并保持它的在工作需求的变化也能用。因此，这个程序将继续不断有用。
你可能不会觉得这个说法有说服力。毕竟，没有一个程序是不可能改变的。但是，有些系统实际上不可能改变，因为改变的成本超过了改变的利益。许多系统在某些功能或配置上达到这一点。
如果你问业务经理他们是否想要做出改变，他们会说他们当然会这样做，但是他们随后注意到目前的功能比任何后来的灵活性更重要。相比之下，如果业务经理要求您进行变更，并且你估计的变更成本高得难以置信，那么业务经理可能会感到愤怒，因为你将系统的变更性达到一个不切实际的地步。
艾森豪威尔的矩阵
考虑艾森豪威尔总统的重要性与紧迫性矩阵（如图2.1）。 在这个矩阵中，艾森豪威尔说：
我有两类问题，紧迫和重要。紧急不重要，重要不紧急。
这句古老的谚语有很多的道理。那些紧急的事情很少是重要的，那些重要的事情很少是紧迫的。
软件的第一个值 - 行为，是迫切的，但并不总是特别重要。
软件的第二个值 - 架构，是重要的，但不是特别紧迫。
当然，有些事情既紧迫又重要。其他事情并不紧急，也不重要。最终，我们可以把这四个对联安排到优先事项中：
- 紧急而重要
- 不紧急而重要
- 紧急而不重要
- 不紧急而不重要
请注意，代码的架构 - 重要的东西 - 这个名单的前两名，而代码的行为则占据了第一名和第三名。
企业管理者和开发人员经常犯的错误是把位置3的项目提升到位置1.换句话说，他们没有把那些紧急而又不重要的特征从那些真正紧急和重要的特征中分离出来。这样的失败会导致忽视系统的重要架构，转而支持系统的不重要特性。
软件开发人员的困境是业务经理没有能力评估架构的重要性。这就是软件开发人员所要做的。因此，软件开发团队有责任判断架构对功能紧迫性的重要性。
为架构而战
履行上述的责任意味着参与战斗，或者更好的词是“斗争”。坦率地说，这些事情时必然的。开发团队必须为他们认为对公司最好的事情而斗争，管理团队，营销团队，销售团队和运营团队也应该这样做。这总是一场斗争。
有效的软件开发团队正在解决这个问题。他们毫不掩饰地与所有其他利益相关者平等地争论。记住，作为一名软件开发人员，你也是一个利益相关者。你需要守护的软件，这是你角色的一部分，也是你的职责之一。这是你被雇佣的重要原因。
如果你是软件架构师，这个挑战是非常重要的。软件架构师凭借其工作描述，更侧重于系统的结构而不是其特征和功能。架构师创建了一个架构，使得这些特性和功能易于开发，易于修改和轻松扩展。
只要记住：如果架构迟迟不出，那么系统开发将变得更加昂贵，并且最终对于系统的部分或全部的改变，将在实际上变得不可能。如果允许这样做，那就意味着软件开发团队没有足够的努力去争取他们有必要知道的东西。