所以我们只需要把这系统的主线架构（事件激发机制）写好，当有需要要加新的奖励规则时，我们只需要让工程师写针对该规则的模块插入即可。同时，我们会对主线架构上的代码进行严格审查，并对插入模块进行出错隔离，这样如果插入的模块有问题，只会影响该模块本身，而不会搞挂掉整个系统。
做产品工程，顾名思义，产品是自变量，工程是因变量。跟产品经理保持好的默契，跟别的组的产品经理和工程师保持好的沟通，至关重要。关于这点要展开说就是另一篇文章了。
九、Uber Android App框架Presidio
我在不同时期也做了很多移动开发的工作。这里我简单谈谈Uber的移动技术栈和App框架Presidio。我将以Android为例。
Presidio是一个组织UI组件和非UI task的框架。先来看看Uber以前的App架构，一般来说，每个UI界面都是按MVVM来写的，在Android的情况下，往往每个界面会对应于一个Activity, View, Controller, Data Manager, 同时该Activity会包括这些View, Controller等等。这种结构往往会导致一个非常大的Controller, 里面有很多不同组的人的代码相互作用，这非常容易给App带来bug，也会延缓试验新功能的速度。
Presidio吸取了这个教训，在组织代码时粒度更小，比如把Controller的功能切分成了Builder，Router，Interactor等等，有点类似VIPER。在这个体系中，一个组件，官方名称为Riblet，包括Router, Interactor, Builder, Component, View, Presenter。而在实现中，我们只有一个Activity, 而在Activity上插了一个以Riblet为节点的树，每个Riblet在被插拔时管理自己的lifecycle。这样也避免了在Activity中使用易出bug的Fragment的lifecycle。
在Presidio中，Builder的主要任务是根据父级传入的参数创建整个Riblet和下层Riblet的Builder。Router是根据lifecycle和Interactor的指令对下层Riblet进行插拔。Interactor是真正的业务逻辑，会根据用户事件或其它事件来做各种决定，并通过Presenter来控制View显示各种信息。
Presidio的另一个优点是不同优先级的模块间的保护（这点是四海皆准）。Presidio主干结构和关键功能上的代码会被严格审查而保证不会有错，而产品工程师为了做实验而开发的Riblet会有默认的flag来关闭，如果实验feature里有bug，最坏的情况是关掉这些非主干功能，从而保证主要功能仍然可以工作。
十、App网络与推送的处理
除了UI，移动端上还有很多其它功能，如各种组件之间通信的和网络通讯。我先说说组件间的通信，一般来说EventBus是一个常用的方式，但是它的不好的一点是所有的组件间的通信都通过一个渠道，这样就缺乏组件间的保护，也不好debug，因为每个激发事件的点都可能是出错点。而RxJava这点就好很多，因为不同的通信是用不同的Observable，所以无关组件间不会相互影响。另外，在代码的组织上，我们可以很干净很容易的把一些列的事件激发和处理串起来，而Event Bus就要繁琐很多。
再说网络通信，通常都是使用Retrofit, 由于它的执行是异步的，所以配合上RxJava就可以把要对返回结果要做的操作串起来。
通常如果客户端的信息有时效性的话，我们需要及时的把信息发给后台，那么我们就需要隔一段时间发些信息回后台，具体的间隔和payload，取决于具体的应用情景。
另外如果我们有后台的消息要发给移动端，我们就需要Push功能。具体的Push其实还分两种，一种就是大家所熟悉的Google Firebase和Apple Push Notification Service，这种Push是不分Mobile App状态而推送过去的，所以即便在App被杀死的情况下，我们可以用它来唤醒App。另一种是App本身可以实现的，只在App在前台的情况下获得推送的功能，这个功能相对第一种来说更轻便，也不需要过Google或Apple。比如说，我们可以试图跟后端保持一个HTTP长链接，然后不时的让后端喂些数据保持这个长链接即可。如果要实现提示消息数，在线提示等功能，这个方案就足够了。
关于网络，我们还需要关注客户端的故障恢复机制。比如在和App通信的数据中心断电了，我们需要让客户端自动跳转到其它备用的数据中心。这就需要我们在移动端事先写好所有的备用选择，并配置各种的降级机制，比如在主数据中心 3次没有响应后跳转到其它数据中心。或者是接到后端的指令后跳转到其它数据中心。