正文
为了实现上述的两个目标，我们选择了Swift。当时我们认为Swift是更加安全的，至少在设想里是的，然而实际生活中并没有人去验证这一点。
我们认为编译器中的类型安全性会让问题更早的暴露出来，而不是等到产品上线以后再出现问题。
而我们知道，从现在开始的这四年，Swift将会进入到一段黄金发展期，它将会成为苹果公司未来唯一一门大力推广的语言。
时间线
从今年年初开始启动的，在二月份的时候，我们当时还希望我们所做的事情是正确的，因为有一些工程师在以前的公司就花费了大量的时间去做重构的事，但最终都以失败告终。为了保证重构能成功，挑选出了几位核心工程师，让他们花了5个月的时间去研究老的架构，在这5个月的时间内，我们就只干这一件事：架构，框架，完成一些基础的工作，最终搭建了一套很完美的基础框架，所有人都是以这套基础框架为原型进行开发。
6月，架构搭建好，开始让核心流团队开始使用。核心流打算采用一种新的uberX骑行或者是uberPOOL骑行，因此我们增加了20位工程师，花了两个月的时间去审查新的架构，确保我们提出来的东西与之前构建一款新产品的要求是吻合的。事实证明，与最开始的产品要求相比，的确遗漏了一些东西，比如在视图层，一旦工程师开始进行转换或者做一些复杂的视图操作，那么我们必须调整架构以满足他们的需求。但是过了两个月，我们取得了新的进展，我们不再需要对代码库进行大量迁移，并且把平台开放给了每一个人，如果他们需要的话，也可以移交他们的功能了。
新架构叫”Riblets”，它是由Router、Interaction、Builder、Presenter、View这几个核心组件构成的，这也是VIPER框架的一种思想。我们研究了VIPER、MVVM和MVC，最终提出的方案是在VIPER基础之上增加一些我们自己创新的元素在里面。最终目标就是将每个功能模块化，并且每一个模块可以独立的进行测试。Riblet框架里的每一个核心组件都有一个协议接口，所以开发者可以把每一个单元单独拿出来，对它进行充分的测试。Riblets框架里的每一个模块都会在树里面进行管理，因此没有状态机，取而代之的是一个状态树。状态树里面的每一个节点就是一个Riblet，新架构中的核心部分是基于业务逻辑的，而不是视图逻辑，并且所有的业务逻辑都是由本地决定的。
以这张树形图里的“注册”模块为例，并不知道它的父节点是谁，但是它所需要的都已经注入进来了，是它的父节点注入了它所需要依赖的东西，可能还会有一个监听器正在监听注册流，但是监听器是不知道注册模块位于树的哪里。所以说，这些模块是完全独立的，每一个单独的模块都会做本地决策。再比如，从“App”模块开始，它仅仅只负责一个业务模块：“目前系统是否有session令牌”，这就是它监听的唯一一件事，如果App模块发现在流里面没有session，它就会把路径指向到“Welcome”处；如果它发现了有session，那么它就会跳过“Welcome”模块，直接进入到“Bootstrap”模块。
之后，树形图里面右边的每一个组件都知道系统目前是处于“已登录”状态，它们都会有一个令牌，它们都可以从独立注入中取到session令牌，它们也没必要去关心用户是否已经退出了。如果在下面的某一个节点处突然进来了一个网络电话，并且最终导致了session无效，那么App组件就会监听到，它就会通过流被调用，然后知道系统目前是没有session的状态，紧接着App组件就会中断Bootstrap树，并且最终将流指向Welcome组件。
这就可以让不同团队之间只关注自己负责的那部分业务，而没有必要说每做一步都需要去跟其他团队进行沟通交流。每个团队都可以做出自己的本地决策，并且依赖关系始终得到满足。
多个文件里面的多行代码
开发过程中会产生很多代码，每一个模块之间我们都定义了协议。有些组件会关联一个Riblit，同时又关联5个不同的文件，因此在代码库里面会有五千多个文件，同时还有五十多万行代码。此外还有一些核心组件是用的Objective-C，这也是完全没问题的。
