1.行为价值

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

程序员们为了达到这个目的，往 往需要帮助系统使用者编写一个对系统功能的定义，也就是需求文档。 然后，程序 员们再把需求文档转化为实际的代码。 当机器出现异常行为时，程序员要负责调试，解决这些问题。

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

2.架构价值

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

软件系统必须保持灵活。 软件发明的目的，就是让我们可以以一种灵活的方式 来改变机器的工作行为。 对机器上那些很难改变的工作行为，我们通常称之为硬件 ( hardware） 。 为了达到软件的本来目的，软件系统必须够 “软”一一也就是说，软件应该容 易被修改。当需求方改变需求的时候，随之所需的软件变更必须可以简单而方便地 实现。 变更实施的难度应该和变更的范畴（scope）成等比关系，而与变更的具体形 状 （shape） 无关。 需求变更的范畴与形状，是决定对应软件变更实施成本高低的关键。 这就是为 什么有的代码变更的成本与其实现的功能改变不成比例。 这也是为什么第二年的研 发成本比第一年的高很多，第三年又比第二年更高。

从系统相关方 （Stakeholder）的角度来看，他们所提出的一系列的变更需求的 范畴都是类似的，因此成本也应该是固定的。 但是从研发者角度来看，系统用户持 续不断的变更需求就像是要求他们不停地用一堆不同形状的拼图块，拼成一个新的 形状。整个拼图的过程越来越困难，因为现有系统的形状永远和需求的形状不一致。 我们在这里使用了“形状”这个词，这可能不是该词的标准用法，但是其寓意 应该很明确。 毕竟，软件工程师们经常会觉得自己的工作就是把方螺丝拧到圆螺丝 孔里面。 问题的实际根源当然就是系统的架构设计。 如果系统的架构设计偏向某种特定 的“形状”，那么新的变更就会越来越难以实施。 所以，好的系统架构设计应该尽 可能做到与“形状”无关。

3.哪个价值维度更重要

那么，究竟是系统行为更重要，还是系统架构的灵活性更重要？哪个价值更大？ 系统正常工作更重要，还是系统易于修改更重要？ 如果这个问题由业务部门来回答，他们通常认为系统正常工作很重要。 系统开 发人员常常也就跟随采取了这种态度。但是这种态度是错误的。

艾森豪威尔矩阵

虽然老调重弹，但其中的道理依然成立。 确实，紧急的事情常常没那么重要， 而重要的事情则似乎永远也排不上优先级。

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

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

来自他于 1954年在西北大学 （No口hwest University）的演讲。

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

1. 重要且紧急

2 . 重要不紧急

3 . 不重要但紧急

4. 不重要且不紧急

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

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

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

4.为好的软件架构而持续斗争

为了做好上述职责，软件团队必须做好斗争的准备一一或者说“长期抗争”的 准备。 现状就是这样。 研发团队必须从公司长远利益出发与其他部门抗争，这和管 理团队的工作一样，甚至市场团队、销售团队、运营团队都是这样。公司内部的抗 争本来就是无止境的。

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

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

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