产品设计时刻：启用/停用/删除，该怎么用？什么时候用？
起因
最近在做BMS计费相关的内容，涉及到了很多基础计费规则的管理。一般来说，对于这种基础规则/配置的管理，就是常用的增删改查显算传一把梭就完事了，但是关于规则的“启用/停用”状态这一点却让我差点踩了坑，恰巧之前我也对这一块有过一些思考和总结，于是就借此机会，写一篇文章来沉淀一下。
遇到的难题
创建好了三个规则，其中规则A和规则B是启用状态，而规则C是停用状态。
接着，在创建某个方案的时候，需要选择使用某个规则。一般来说都会做一个限制，就是：只能选择“启用”状态的规则。
以上的内容是一个工作中很常见的场景，一般大家也都会使用上述的方案来解决这个问题。
但是如果此时，换个视角来思考这个问题，可能很多产品朋友就会发现自己平时并没有注意过这一块的逻辑，是一个小小的盲区。
关于删除，一般常用的方式是通过规则去反查方案，如果规则被方案关联了，则不允许删除；或者是方案被废弃了/停用了之后，才允许删除。
关于停用，一般来说会有两种处理方式。一种是反查关联性，判断是否可以停用；另一种是不做关联性判断，直接停用，等具体使用到了此规则的时候，再判断状态是否可用。
第一种方式和上面的删除的方案是一样的，这里主要聊一下第二种直接停用的方式。第二种方式会有一点小坑，需要注意一下。
当规则停用了之后，编辑方案的时候，是否需要默认带出停用了的规则？
例如，账号和角色关联就是一个很常见的功能，账号可以停用，角色也可以停用。但是角色被停用了之后，账号虽然还是关联了这个角色，但是失去了相应的权限。
上面的图片是从谷仓的OMS中找的截图，当角色被停用了之后，编辑一个关联了此角色的账号时候，还是会带出原来的绑定数据，但是点击下拉的时候，是找不到被停用了的角色的。所以如果不点击编辑，其实是判断不出来角色已经被停用了，即使点击了编辑，也需要切换了不同的角色之后才能发现原来的角色被停用了，其实已经不能再选不中了。
这个处理逻辑是正确的，但是也是有体验不好的弊端，可以试着优化一下。如果能在编辑的时候直接对角色加上一个tag标识，提示这个角色被停用了，应该会更好。对了，这个地方还有一个不算BUG的BUG，角色被停用了之后，这里展示的是角色的id，看起来也有点奇怪。
怎么解决的
看完了上面的案例，再回到停用规则这个问题上来，我们也可以效仿“账号-角色”的关联方式来处理。如果停用了规则，则对应的方案还是关联了此条规则，只不过是方案可能不能生效而已，因为关联的规则被停用了。
但是由于在做的计费方案，关联了很多个规则，这样就会在使用上带来一些弊端：明明方案关联了规则，但是却不能生效，逐个排查了之后才发现，原来是某个规则被停用了，所以导致了方案未能生效。
鉴于上面的分析，我们内部讨论了之后发现，两种方案都各有利弊，但是考虑到规则的维护和管理的难易程度，以及方案未生效之后的排查难度等。
最终的方案是：我们对大多数规则都没有做“启用/停用”的状态。
原因如下：
一个规则会被多个方案所引用/关联，如果规则停用了，那么方案可能也会受到影响，由于关联的对象太多了，这样做一些关联性判断的时候会增加很多工作量，需要去反查分别被什么方案关联了； 对于很多规则来说，配置起来并不是很复杂，成本不会很高，所以启用和停用的状态用途并不大，如果想要停用那就直接删除就好了； 停用和删除，在很多场景下会有重复的作用，用户一时间不知道该选择停用还是删除，过多的使用停用可能还会造成更多的冗余数据；
虽然大多数规则是没“启用/停用”状态，但是针对一些特殊的规则还是保留了“启用/停用”状态的，这些规则一般会有以下一些特征：
配置比较麻烦，如果暂时性的不想要可以停用它而不是删除，因为删除后再重新配置比较费时间； 关联性不是特别复杂，哪怕是同时有“启用/停用”和“删除”功能，但是关联性不是很多，逻辑判断不会特别复杂，兼顾的业务场景也比较多；
总结
关于“启用/停用”，最开始我一直采用的一个设计方法论是：如果配置比较复杂，则加上“启用/停用”，如果配置比较简单，则不需要加上这个。
但是经过这一次项目的小风波之后，我发现除了考虑这一层因素之外，还需要考虑一下关联性的问题。如果关联对象多，关联的链路长，则尽量少用多余的状态字段，这样会导致开发、测试、使用的时候都更麻烦。
还有一个小细节要注意的就是，一定要和团队中的其他产品、开发、测试等沟通好一个通用的解决方案，这样可以打消很多不一致的疑惑感。让大家都知道，到底什么时候用这个状态，什么时候不用这个状态。
以上便是最近项目的一个小小感触，希望对大家有所启发。如果对这一块你也有其他的感触和见解，也欢迎留言与我交流。
