Rx在一個項目上實踐后的總結：
1、需求，還是要把需求理清；否則就算是Rx也幫不上你
先對需求做功能分解，每個子功能之間可以有先后依賴，以及包含關系，但功能之間的邏輯必須完全獨立，不能有依賴、包含關系；
2、Rx vs 傳統
傳統方式（過程式）做好的話，也有上面的分解動作，但缺點很明顯，所有需求的實現都是HardCode，基本上主流程只有一個，當需求變化時（現代社會這是常事），在一處修改代碼實現了功能，往往需要在多處修補Bug，才能不破壞原有的功能，導致該主流程會越發臃腫，甚至會到達不可維護的地步；
Rx就是為了解決這個問題，拋棄了由HardCode實現功能的方式（此路“最終”不通），而是采用聲明式編程（編碼方式為：定義什么情況下要做什么事），由情況（Event流）來把整個需求要做的事情串起來。
3、Rx的正確使用姿勢
需求理清的基礎上，子功能也都分解成獨立的了，為每個子功能定義觸發的條件；
然后為該條件定義一個Observable變量，功能的處理就是該Observable的訂閱（聲明式）；
這些已定義的Observable就是樹的葉子，還需要找到并定義事件的源頭—即樹的根；
【重點】仔細設計根和葉子之間的關系，從葉子這端開始回溯，只要2個葉子有重復處理的部分，就需要新建一個Observable，并定義為分杈；2個分杈重復處理的，再新建定義為父分杈，直到最后該分杈可以單線聯系到根；
最終達到：該樹的根到每個葉子都有且只有一條“唯一路徑”；
剩下就很簡單，在葉子Observable上添加訂閱函數即可。
簡單來說就是：定義Observable，然后訂閱處理。
【反例】如果把需求實現插入到其他地方-如doOnNext，或一個訂閱處理了多個邏輯，就會造成邏輯混亂，和傳統方式（過程式）面臨的問題一樣，而且還會更糟。
反模式太多，可以認為除了這條最佳實踐外的都存在反模式嫌疑，且了解價值不大，遂略去。
