Rx只有一条最佳实践

Rx在一个项目上实践后的总结：

1、需求，还是要把需求理清；否则就算是Rx也帮不上你

先对需求做功能分解，每个子功能之间可以有先后依赖，以及包含关系，但功能之间的逻辑必须完全独立，不能有依赖、包含关系；

2、Rx vs 传统

传统方式（过程式）做好的话，也有上面的分解动作，但缺点很明显，所有需求的实现都是HardCode，基本上主流程只有一个，当需求变化时（现代社会这是常事），在一处修改代码实现了功能，往往需要在多处修补Bug，才能不破坏原有的功能，导致该主流程会越发臃肿，甚至会到达不可维护的地步；

Rx就是为了解决这个问题，抛弃了由HardCode实现功能的方式（此路“最终”不通），而是采用声明式编程（编码方式为：定义什么情况下要做什么事），由情况（Event流）来把整个需求要做的事情串起来。

3、Rx的正确使用姿势

需求理清的基础上，子功能也都分解成独立的了，为每个子功能定义触发的条件；

然后为该条件定义一个Observable变量，功能的处理就是该Observable的订阅（声明式）；

这些已定义的Observable就是树的叶子，还需要找到并定义事件的源头—即树的根；

【重点】仔细设计根和叶子之间的关系，从叶子这端开始回溯，只要2个叶子有重复处理的部分，就需要新建一个Observable，并定义为分杈；2个分杈重复处理的，再新建定义为父分杈，直到最后该分杈可以单线联系到根；

最终达到：该树的根到每个叶子都有且只有一条“唯一路径”；

剩下就很简单，在叶子Observable上添加订阅函数即可。

简单来说就是：定义Observable，然后订阅处理。

【反例】如果把需求实现插入到其他地方-如doOnNext，或一个订阅处理了多个逻辑，就会造成逻辑混乱，和传统方式（过程式）面临的问题一样，而且还会更糟。

反模式太多，可以认为除了这条最佳实践外的都存在反模式嫌疑，且了解价值不大，遂略去。