项目中的大改动

前因

用户对程序员说：这个导出的目录文件（HTML）有两个问题：一个是点击链接打不开，另一个问题是用表格方式不贴近现实作为一个目录页面的格式。

程序员表现出有点无奈，也有点惊讶和一点愤怒。总的来说，改动不是问题，问题是需求之前不是谈好了吗，现在说改，则浪费了一天的时间。

项目需求改动

针对输出格式的改动，在行业是很普遍的：这里字体大一点，这里颜色调深一点，这里用表格方式展示这些数据，那边用一个柱状图来展示…… 相信这些改动，做过项目的人绝不会陌生。这些改动，相对另外一些改动（后面会解析），是比较容易的。

系统中可能的改动，按一般代码分层结构来看，大致可分为：

1. 界面改动（包括界面／通讯接口格式／系统与外部世界交互的地方）
2. 逻辑改动
3. 结构改动（数据模型、领域模型）
4. 框架改动

越在上层，感觉改动越容易，原因改动的底层不受影响，只影响上层的代码，改动量比较少，这是代码结构分层的必然结果。

假如你改动业务逻辑，你所需要操作的界面很大机会要改掉，甚至重做。同样道理，如果你改动数据结构，你的整个逻辑算法都得改掉，但是否需要改动界面，就看数据结构的改动如何影响逻辑算法暴露给上层的接口，隔离不好的，或者逻辑根本不兼容的，界面层一样要改。

通常，业务不会干涉技术用什么框架的，所以框架改动存粹是技术选型或者遇到某些瓶颈后需要研究的改动。通常这些改动由技术团队触发，举证说服业务团队要作这些技术改动。

业务中，最麻烦的是结构改动，这里说的结构包含：

• 数据模型结构
• 领域模型结构

例如本来一个订单只对应一个商品，业务想把一个订单改为对应多个商品。本来是1对1，变成1对多。

又例如一笔付款本来只能付一个订单，业务有可能改成付款可以付多个订单，甚至一个订单可以分多次付款。本来是1对1，变成多对多。

类似以上的改动，基本属于大改动，是牵一发动全身的（上面几层都得重新设计和修改，改完又要测试等等一大堆事情）

注意貌似简单的改动

以下例子说明：一个逻辑层的改动，其实背后真正的范围不仅仅是逻辑层：

• 业务：我们需要按订单金额，奖励红包
• 技术：等等……你说红包？
• 业务：是啊，发个微信红包就好了。不用改太多东西
• 技术：那行，我就调用一个发红包的接口就行了
• 业务：我都说我们技术是最牛逼的的

某一天，发送红包的接口失败了。具体那些订单有没有成功发过红包，没有记录下来。

• 业务：你们不是记录了那个订单发了红包没有吗？
• 技术：我们没记录呀，你没说要记录的呀
• 业务：一般正常的都需要做记录的吧
• 技术：那就做一个记录呗，发红包失败需不需要重试？
• 业务：那当然
• 技术：一直失败怎么办？
• 业务：监控报警，让我们来跟供应商协调处理
• 技术：报警记录需不需要做状态变更，比如说‘业务处理完毕‘之类
• 业务：不用太复杂
• 技术：好，报警记录就不用记录状态变化

想不到就加一个发一个红包逻辑，衍生出一个监控报警系统，而业务很大机会因为报警太多无法跟踪，最后也需要跟踪处理状态。

一个简单逻辑，有可能衍生出一整个独立领域的系统（一套全新的业务模型+逻辑+界面）。

回顾

用户对程序员说的目录文件的问题，其实是一个界面层的改动。HTML点击打不开，那就换另外一个格式（如Word）能点击链接打开就好了。

本来用表格方式（HTML的 <table>），其实当我们换一个展示格式，表格方式其实需要重新实现了，而是不是再用表格，反正都要重新实现，已经不需要纠结了。

程序员核心想要表达的是：为什么需求不确定好再开发呢？

界面这表现层的东西，本质上就是有人说好，有人说不好。有人需要点击直接打开，有人可以忍受保存后再打开，这个和逻辑和数据结构有着本质上的不同，业务定义上总的有个共识说：究竟一个订单可以包括一个商品还是多个商品。如果业务定义上也存在一种类似界面般的，包含各种个人喜好的歧义，那么系统改动肯定是没完没了的。