后期状态修改时，如何以最小成本进行修复

后期状态修改时，如何以最小成本进行修复

设计一些流程复杂的数据结构时，经常采用的解决方式就是使用一个状态保存各个状态，比如：

• status
  
  • 1：未审核
  • 2：已审核
  • 3：异常
  • …

原先设计结构的时候没有想到后期发生改变了，比如多了一个新的状态叫“待定中”，这个时候你有两种方式，一，修改以前的代码，二，跟产品经理吵一架，以强硬的态度以及各种专业术语企图让产品经理放弃这种修改，但是假设，你不幸战败了，这个被列入了开发计划中，你一想起以前那成堆的代码，而且没有很好的实现底层，这个时候你要修改的代码量简直是让人望而却步，而且你知道，这种草率的修改，肯定会引起Bug，那么你就更不想去修改了，那么在这样的情况下，该怎么做，才能在最小改动的情况下，去实现你的功能呢？

首先，不要去修改老的状态值，原先的值是怎么设置的就这么设置，这样可以保证，在走出新加的状态，这种对原先状态来说“异常”状态之后，你原先的流程是可行的，这样你需要修改的代码量也会减轻。

接着就是修改前端页面的显示，你需要明确的是，产品经理，或者客户最终能看见的其实就是最终呈现的页面，他们对你怎么存数据，怎么实现这个功能的一点都不在乎，所以你与其修改原先的业务逻辑代码，不如在显示给用户的界面上动点手脚，你不是加了一个状态叫“待定中”吗？那我就把“待定中”的那条数据标志为异常，等你把这个异常处理完之后，我再来给你显示剩余的操作内容，这样你也没异议吧，因为这条数据异常了啊，当然要等你异常处理完之后再执行别的操作了。

而且代价就是新建一张表，存储这种异常的情况的数据，到时候将正常数据与异常数据一比较，就可以筛选出异常的数据了，由于异常的数据量不多，当然多了肯定也有多了的解决办法，所以你也不用担心新加入的流程对系统的压力。

实际例子

举一个我遇到的现实场景，我需要输出一个用户的所有合同，原先合同是没有问题的，但是一天客户提出一个需求：我不想让我的销售人员能随意修改合同了，他们需要提出申请，申请通过后才能始这次的修改生效。

那个时候我想到的解决方式是在合同表中加一个字段，叫：is_edit，当这个字段为0时，表示该笔合同没有处于编辑申请阶段，如果1则是处于该阶段。本来这样是没事的，也能解决问题嘛，撑死了跟原先的业务代码兼容性差一点。

后来这个客户又提了一个需求，删合同也要审核，这个时候啊，再加一个字段？把原先的is_edit字段内容扩充，加一个状态叫做删除中？不行，这些都是暂时解决问题的方式，一定有一种更好的方式。首先，对用户来说，他们要的其实很简单，一旦提出了申请，那么在申请通过前，销售都不能对该笔合同进行任何操作，所以我只需要在状态那一栏里现实“编辑申请”中，接着就是控制操作按钮的输出，这个简直是小 case嘛，所以我才用的解决方案：

• 新建一张表，存储特殊状态的表，当特殊状态解决后就删除对应的记录，显示自动更正为原先的业务逻辑：
  
  • unusual_table
  • contract_id 合同id
  • type 错误类型 1 编辑申请 2 删除申请

好了，这样我就记录了有异常的合同与异常的类型，接着就是在输出对应值时，查看一下，对应合同的id是不是在这张表中，而一般情况下，这种异常的情况不多，所以不会影响性能。

• 异常处理完成后，把user_table中对应的字段去掉，显示限制去掉了，恢复原始的业务逻辑，基本上不用修改原始的业务代码，只需要在显示上进行限制就可以了。