句句属实，90%的人都被需求整“哭”过！

业务需求永远第一

没有和 PM 吵过架的 RD 不是好 RD，那没有被需求整哭过的人生不是完整的人生。

一直以来，PM 和 RD 就是一对欢喜冤家。
“这个需求很简单，就是加个按钮”
“你能不能想清楚再提。这个需求能带来多大收益？”
“小哥哥，我要改个颜色，马上上线，急”
“能不能晚点和其他需求一起上线？”
...

现实中，PM 的需求有时候就是合理的；现实中，有些 RD 的疲于应付就是架构设计不到位；现实中，有时候哭过的 RD 才能成长得更好。

下面我们就来看下这个场景。

典型场景 

相信在很多业务下我们需要定义一些规则，比如满足规则 A，则 xx1，满足规则 B 则 xx2。用一个“高端”一点的表达就是一棵决策树，很简单的需求。

图一：规则的决策树表示

基于这种思维方式，在一次活动期间，我们需要对参与活动的人进行风险控制。PM 的需求很简单：两个人是好友，则 3 天内只能使用 1 个优惠，两个人不是好友，则 3 天可以使用 2 个优惠。

用决策树表示则为：

图二：需求Demo

  程序员成长之路 

01 /  程序员1.0

无知者无畏

涉世未深的程序员，看到这个需求后，心里暗暗的觉得“so easy”，不就是 if/else 轻松解决么。

有经验一点的程序员，心里盘算，PM 是易变的生物，这些“几天几个”肯定要变来变去，得配置化。

因此针对这个需求的 1.0 版本：

图三：基于纯业务开发的系统

看似完美的解决方法，上线后，等待程序员的苦日子就来了。

• 我需要把某棵树的 A 节点和 C 节点重新组织，形成一条行的规则。

• 我需要修改阈值，修改时间范围。

• 我需要根据不同的规则，触发不同的响应。

    。。。

拥抱变化，程序员 1.0 开始忙于改配置、测试、上线。随着策略变复杂，需求变化更快，上线出问题也越来越多。程序员 1.0 开始应接不暇了，开始频繁的出错，决策树代码复杂而不可维护了。

我明明很努力，怎么结果就这么不好呢。凌晨下班的1.0，落下了“不甘心的泪”。

02 /  程序员2.0

迭代是互联网的利刃，也是我们程序员持续成长的法宝。

2.0 版本的程序员，吸收了前面的经验教训，在决策树的原理上，复用最大化。我们将决策树的每个节点都按照最小化规则来组织，抽象最小规则元素。

图四：最小规则抽象

特征：按照一定业务逻辑实现的类型。比如是否好友、3天使用优惠数量等等

阈值：配置的触发规则的值

逻辑判断：用于比较特征和阈值之间关系的实现。

对于决策树的分叉，在逻辑上可以抽取成独立的链式关系。即对于图一，我们可以抽象出 ABB1/ABB2/AC 三条规则链，且三条规则链相互独立。

图五：链式规则

对这个链式的规则结果进行统计，将得到和决策树一致的结论，但是节点的存储和组织更加的冗余了。

基于这个认知，我们做了一个规则引擎：

图六：基于最小节点的规则引擎设计

所有的节点都格式化成：特征、阈值、逻辑判断 三要素

所有的决策树打散成独立的链式节点

标准化，表示我们可以搭建一套很完整的产品管理后台，彻底释放RD的生产力。

程序员2.0 松了一口气，总算熬出头了。

03 /  程序员3.0

追求更高、更快、更强。

自研的规则引擎就完事了吗？显然不是，程序员成神的道路没这么简单。

相同的需求，隔壁公司会怎么做？比如美团Maze框架？

基于链式规则不够精简，是否用DAG（有向无环图）方案更科学？
开源的Drools 有什么优缺点？

实现功能的方案有很多，NX的架构师，不会唯技术论，也不会让自己跟着需求追。

这个时候有一句名言“任何脱离业务场景谈架构，都是耍流氓。”（没错，就是我说的。）

在成大神的道路上，必定充满坎坷。有些人需要3年，有些人需要5年，但人生有多少个5年。我创业做IT教育培训，就是希望能够帮助技术人，做好指路人，用我的经验，将场景与技术结合，让技术人具备更高的架构设计能力，节省最宝贵的时间成本。

 -END- 

推荐阅读

7. 图解：这才是程序员加班的真正原因！

好看就点在看！