用数学公式谈谈需求变更与架构调整

背景

因为很偶然的原因，来到了现在的团队，并从事很有兴趣但从未接触过的游戏服务端开发。过去的一年多，整天琢磨分布式、序列化、事件。中间，经常遇到牙膏式的需求变更，那个酸爽，一言难尽。你怎么谈复杂性、银弹……，统统没用。
某夜失眠，无意中想到以前在头条看到的一道数学题，很好说明需求变更、架构设计面对的问题。正好拿来练练笔。

题目

列举出0到9，然后用四个相同的数字，通过常用的运算符来匹配，使其等式成立，比如用3：
$$\begin{gathered} 0=3333 \\ 1=3333 \\ 2=3333 \\ 3=3333 \\ 4=3333 \\ 5=3333 \\ 6=3333 \\ 7=3333 \\ 8=3333 \\ 9=3333 \end{gathered}$$

作为受过高等教育的我们，可以很容易弄出答案：
$$\begin{gathered} 0=(3+3)-(3+3) \\ 1=(3+3)÷(3+3) \\ 2=(3÷3)+(3÷3) \\ 3=(3\times 3)-(3+3) \\ 4=\sqrt{3\times 3}+(3÷3) \\ 5=(3+3)-(3÷3) \\ 6=(3+3)+(3-3) \\ 7=(3+3)+(3÷3) \\ 8=(3\times 3)-(3÷3) \\ 9=(3\times 3)-(3-3) \end{gathered}$$

需求变更

我们的业务需求，好比左边的数字。而右边的数字与组合，就好比我们采用的开发语言与对应的框架。
对于变更，比如1->2，很简单的调整，右边的规则却又很大的变化。运气好，框架唉支持能力强，或者前期建模能够适应，那么调整还不算困难。但那是偶尔。如果借用代数术语，运算符号的变化，就是函子发生了变化，代码规则必然跟着调整。
再有需求变更，把这个题交给产品试试，或许更形象一点。当然，我们是期望能够一次性的多了解需求，这样，即使迭代，我也知道大概怎么调整更好。比如预知5->6，我们架构上提前考虑了适配，后期改动就会更小。用公式表达就好比这样：
$$\begin{gathered} 5=(3\times 3)-(3÷3) \\ 6=(3\times 3)-(3-3) \end{gathered}$$
仅仅改变了一个符号而已！

最后

这公式还表达了另一个现象：有时候，看似很小的变更，还不一定能实现。好比之前的1，我要变成1.1，求解。怎么弄？？