一个例子

每两周的一个周四是一个比较特别的日子，争执，妥协，痛苦，火花，所有的一切都是为了一个更好的产品。一天下来有点筋疲力竭的感觉。

今天的话题补充上周文章后，大师给我的要求，叫举个例子，就拿今天白天大师自己的一个案例来举个例子。

上次说到应对不同需求的SaaS产品，核心逻辑做配置，输入输出做分支。

我们有一个客户，通过接口给我们传输订单信息，在之前的版本中，提过一个需求说是，对于接过来的订单，需要人工确认后才能指派承运商。

为了不影响大部分的客户，我们增加了一个配置说：
接口过来的订单是否需要人工确认。
对于这个客户配置成需确认，对于其他客户配置成待确认。

想想挺对的。不料上周客户又提了需求的调整说，在某种业务模式下需要确认，其他的不需要确认……

哦，有点懊恼，不做吧，难以满足客户的需求，而且客户还确实有实际情况来支撑这种需求，做吧，再一次增加了系统的复杂度，增加了潜在风险……两难。

大师这时候提出了一个方法，说既然是这个客户的接口逻辑，和不直接在他们的接口转换中处理，不需要设置什么规则，也不需要影响现有其他的客户。

我认为这是一个看似不太好写死了逻辑，实则是一个挺不错的方法。

1，降低了系统的复杂度，不需要设置规则来判断分支。

2，消除了客户之间的相互影响。

3，降低了后续继续修改的难度，在单独的接口罗技中修改，显然难度和风险更小。

完美的复合了简单，清晰的标准，契合了我上周说的输入输出写分支原则。

就这么愉快的决定了。

当然这个解决方案还有两个弊端或者说隐患需要考虑：

一是后续需求变化的响应速度，配置的方案如果后续的变化在目前的考虑范围内，明显是及时修改生效的，但是写在接口逻辑中，按照我们现在的流程，修改需要等至少两周。这一点是需要研究改进的。

二是逻辑的隐蔽性，写在接口逻辑中，因为处在一个边缘的分支中，其中的逻辑很有可能会很快被遗忘，导致白盒变黑盒。特别是我们现在多次迭代修改同一块逻辑之后，就对我们的接口文档提出了较高的要求。

当然，我还是认为，为了简单清晰的产品设计，这两点隐患是需要克服，或者是需要想办法改善的。

最后记录一下日常：昨天和蛋哥讨论了一下体重的问题，他的观点是越是忙，越是难以控制体重，体重将会有一个大幅反弹，深以为然，特别是心累的时候。就像之前看过网易邮箱的每日一句问候语：疲劳是一座迷宫，食物是唯一的出口。为了从精疲力竭的状态中拜托，猛吃了一顿晚餐，再写篇文章排遣一下，基本上就恢复了。

一个例子