软件想要什么之二：变化之解

问题根源

在软件想要什么之一：分布式一文中，我们提到软件想要的三个更简单的底层解决方案，分别是虚拟集群、消息广播和事实流。这些是与运行有关的因素，而从软件开发的角度来看，还有一些设计与开发相关的因素也是需要我们考虑的，其中最根本的问题是，如何应对需求的变化，这几乎是所有软件工程问题的根源。

如果你曾经经历过一个周期超过2年的软件开发项目，你一定会对以下问题深有感触，如果你竟然曾经是这样的软件项目的项目经理或开发主管，那么你一定更是对此有切肤之痛：

1核心系统越来越复杂，随着业务的增长，代码不断增长，基本上没有任何一个程序员能够完全理解整个系统。2要增加一个新的功能，或者修复一个bug，已经变得非常吃力，并且极其耗时。3这种系统的复杂性，也会增加测试的复杂度，为了保证上线的时间，测试团队只能进行部分的回归测试，给生产环境系统增加了潜在的风险。

当我们分析以上问题的原因时，往往会将其归结于软件的复杂性，但是，如果换个角度来看，或者说从复杂性这个现象进一步分析其本质或底层原因，我们可以发现，变化才是所有问题的根源，因为任何系统一定都是从相对简单变得越来越复杂和不可控的。

变化之解

应对变化，相信任何人都不会质疑这是软件工程头等重要的问题，也是任何软件开发项目成败的关键。但实际工作中，很多团队并没有正视这个问题的重要性，所以才会大面积出现以上问题。在进一步讨论这个问题之前，我们先抛出一个普遍规律：无论什么事情都是有方法论的，越是重要的事情，越是必然有方法论存在，而且越是必然有更好的方法论存在。如果你之前没有意识到这个普遍规律，那么相信我们，你并不孤独，如果你竟然也和我们一样相信这点，那么很显然，我们应对这个软件工程领域无比重要而又看似根本无解的问题，其根本解决方案只能是：建立或者优化应对变化的方法论，如果之前没有的，必须建立，如果有，必须优化。

无论这个破解变化的方法论是什么，都需要能很好地匹配软件开发各个阶段不同的变化特征，对于阶段划分不合理的团队或企业来说，可能还需要重新规划其对软件过程的阶段的划分。下面我们按从前到后的顺序来分析：

1. 价值层软件从高层来说需要做什么，这最主要是由企业的客户价值主张决定的，这个价值主张同时也是商业模式的核心，往往与企业的战略目标甚至价值观都有关，所以这块的变化应该慎之又慎，对应到方法论，就需要我们在用户角色和价值主张分析上所做的工作要充分，以确保软件的主要特性都是有价值的。2. 多变层

对每种用户或角色，我们通常会通过用户故事，以客户能够明白的方式，描述软件系统的外在行为，这时对系统的内部动作是完全忽略的。

用户故事之内，往往会细化多个场景，主要用来描述用户与系统的具体交互，这种交互的描述，最典型的方式是通过原型设计，或者更轻量和易复用的交互模型来进行，而服务端所需要提供给UI调用的接口（最常见表现形式为Rest API）的定义，也可以由这些交互来决定的，从而看做是交互中事件的细节。

这部分的内容，往往是最易变的，那么我们从方法论上来说就应该把这部分和其他部分完全隔离开来，从而减少变化的扩散。

如果你的团队在这个环节就在进行所谓的领域建模，相信我们，你并不孤独，但请深入思考一下把领域引入到这个阶段是不是正是你们把软件一步步做成巨大的单体的主要原因。所以，在这个阶段，请只把数据看做DTO或Schema。

3. 精炼层

从接口实现往后的部分，是系统最重要的部分，也是上一篇关于软件想要的主要变革所发生的部分，你应该尽量让这部分的变化比上一部分低一个维度，DDD里所提倡的精炼就有这层含义，这部分是系统的精华，如果说软件是工程与艺术的结合，那么可以认为前一部分是工程，而这部分是艺术，并且是语言与艺术的合体。

如果在这个阶段你从来没有对一个词的含义进行过深度剖析，比如从来没有为一个概念查过Wikipedia或韦式词典，请相信我们，你并不孤独，但是你有可能错过了很多。

4. 支撑仅仅意识到每个阶段的变化特征和应对策略是不够的，至少对2、3两个阶段，我们还必须全程有活文档体系作为支撑，这个活文档，最好是文本为主，并也像代码一样用SVN或Git管理起来，以便可以随时查阅历史变更。

▼变化之解

Action

总的来说，软件想要我们具备应对变化的能力或方法论，而不希望我们主动去预测未来，想想之前你们团队是不是经常处于一种试图尽可能地预测未来，甚至是穷举未来的状态中，如果答案为是，请相信我们，你并不孤独。变化之解最核心的目标，就是建立一套方法论，它让我们能不用过多地去预测未来，却有能掌控未来的信心。

更多精彩，请看微服务到底微在哪里：无为而微