两个价值维度

一、行为价值

软件系统的行为是其最直观的价值维度。程序员的工作就是让机器按照某种指定方式运转，给系统的使用者创造或者提高利润。即把需求文档转化为实际的代码，当代码运行出现问题时修复它。

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

二、架构价值

软件系统的第二个价值维度是软件的灵活性，软件系统必须保持灵活，软件必须够软（software的soft）。当需求方改变需求的时候，随之所需的软件变更必须可以简单而方便地实现。

变更实施的难度应该和变更的范畴（scope）成等比关系，而与变更的具体形状（shape）无关。所以，好的系统架构设计应该尽可能做到与“形状”无关，即不要依赖具体细节，要抽象出来。

三、哪个价值维度更重要

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

如果让业务部门回答，肯定是系统正常工作重要，但是研发人员必须认识到业务部门这种认识是错误的。

为什么呢，毕竟理论上没有什么程序是不能修改的。但是，现实中有一些系统确实无法更改，因为其变更实施成本会远远超过变更带来的价值，变更代价太大！

如果你问业务部门，时是否想要能够变更需求，他们肯定回答是而且会说：完成现在的功能比实现未来的灵活度更重要。但讽刺的是，如果后面业务部门提出了一项需求，而你预估的工作量大大超出他们的预期，这帮家伙会对你放任系统混乱到无法变更的状态而勃然大怒。

所以技术人员要懂得控制复杂度，以保持系统的灵活度。

四、 艾森豪威尔矩阵

美国前总统艾森豪威尔将事情分为四个象限：

1.重要且紧急

2.重要不紧急

3.不重要但紧急

4.不重要且不紧急。

系统行为：是紧急的，但并不总是特别重要，占据第一和第三位

系统架构：是重要的，但并不总是特别紧急，占据第一和第二位

业务部门与研发人员经常犯的错误就是将第三优先级的事情提到第一优先级。即他们没有把真正紧急并重要的功能和紧急但不重要的功能分开（1和3）。这导致重要的系统架构问题让位给了不重要的系统行为功能。

 

研发人员要明白：业务部门原本就没有能力评估系统架构的重要程度，这本就该是研发人员的工作职责！

所以，平衡系统架构的重要性与功能的紧急程度这件事，是软件研发人员自己的职责。

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

为了做好上述职责，软件团队必须做好长期斗争的准备，现状就是这样，研发团队必须从公司长远利益出发与其他部门抗争。

有成效的软件研发团队会迎难而上，毫不掩饰地与所有其他的系统相关方进行平等的争吵。请记住，作为一名软件研发人员，你也是相关者之一。软件系统的可维护性需要你来保护，这是的职责之一。如果你是软件架构师，这项工作就加倍重要了。软件架构师这一职责本身就应更关注系统的整体结构，而不是具体功能和系统行为的实现。软件架构师必须创建出一个可以让功能实现起来更容易、修改起来更简单、扩展起来更轻松的软件架构

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