-
一、通用方案的设计
- 业务解耦
既然这个新方案要求的是通用，那么这个方案在设计之初，最根本的思想是解耦，
尽可能不要依赖到其它业务逻辑。
- 举例
比如如果是一个气泡渲染的通用方案，那么我们的方案就应该是全新的，
这个方案中，控件渲染的文案、样式和配置都尽量在方案内闭环。
比如：
- BubbleInfo
- type
- wording
- iconUrl
二、通用方案的扩展
通用方案设计完成后，后续一定会对通用方案新增功能，
工程上出现过很多次通用方案设计之初是通用的，但在后续的维护和扩展中，慢慢变得不通用起来。
可以说：维护和扩展一个通用方案花费的精力，要远远高于最初设计这个通用方案所花的精力。
那么，通用方案变得不再通用可能会是哪几种原因导致的呢？
- 依赖了某些非通用方案
还是以上面的气泡渲染为例，如果客户端需要读取渲染气泡的时机，代码这么写了：
if BubbleInfo.type == xx
duration = yy
当代码里关于这类逻辑越来越多时，通过xx type，去读取yy的逻辑，就变得不再通用。
因为duration一定捆绑了xx type，如果后续要新增type对应的duration，
那么客户端是一定要发版本进行修改的，且非常容易出现后台新增type，未同步到客户端导致的duration读取问题。
所以最好的方法应该是：duration 应该也要在 BubbleInfo 配置中下发。
- 过于相信产品导致的维护危机
我们都知道产品推业务是很紧急的，关于BubbleInfo的优先级问题，产品经常会说：A type 的气泡优先级一定是大于 B type 的，以后也不会变了，就这么上线吧。
那么代码里就出现了类似下面的代码：
if BubbleInfo.type == A
xxx
else if BubbleInfo.type == B
yyy
这样就会导致业务逻辑过于hardCode，后续换产品同学，他可能并不理解为什么A一定大于B，他想进行调整，那么只能客户端在新版本进行调整了。
所以遇到类似问题时，作为开发一定要坚持底线，不能为项目埋坑，在这个需求背景下，我们应该要做的是给 BubbleInfo 新增一个 level 优先级的字段，
由后台来控制 A和B 的优先级。
但如果是你来接手这个需求，你是立马在客户端写上 A > B 的业务逻辑测试上线，还是找后台去申请字段联调测试呢？
三、小结
所以说：通用方案的设计难度是6的话，那么维护其所花费的心血就是8，一个通用方案被设计出来，
只是通用方案整个生命周期的30%，维护和扩展的工作实际上更决定着该通用方案是否真的可行。