一个书呆子在新的Swift iOS应用程序项目中使用的第三方开放源代码框架列表。
如果您是老牌产品公司的一员，通常就没有经常从头开始新项目的奢望。 不久前， Facebook 将 其混合应用程序 迁移 到了本地Objective-C。 Lyft 和 Uber 确实将其旧的Objective-C应用程序重写为现代Swift语言。 几乎没有其他人敢这样做，这是可以理解的，这是因为成本高昂，并且有可能完全重写奶牛核心业务应用程序。 我很荣幸地体验到Uber重写的感觉，我看到了它的巨大努力以及每个人需要的承诺水平。 如果可以的话，我很乐意回想一下，重新体验一下。
作为一名工程师和有抱负的技术领导者，对我来说最重要的收获是，开发团队中普遍接受的实践的选择以及底层工具和编程范例的选择对成功的开发产生了巨大的影响。软件项目。 通过尽早做出正确的决定并进行良好的沟通，开发人员团队可以取得巨大的速度并将其维持很长一段时间，而不会积聚技术债务，继续保持应用程序架构的清洁和可维护性，并且不会互相踩踏。
我最近开始了一些新的iOS应用程序项目。 最大的花费了我两年的时间，才是功能完善的本地iOS消息传递应用程序。 在进行这项工作时，我能够尝试多种方法和架构模式，并观察它们的配合情况。 这次经验最大的收获是与整个应用程序的体系结构保持一致，这与我在一家大型工程组织工作的经验100％匹配。 您无法有效地将入职部件中的MVC与Redux进行设置结合，而将VIPER（或RIB）与其他地方结合使用。
对我来说，最有效的方法是在项目开始时获得足够的速度，并在项目的整个生命周期中保持速度，这是使用一组第三方框架，这些框架具有足够的高级抽象能力，并遵循精心选择的单一架构原理，不要在应用程序的不同部分中混合抽象级别。 作为团队负责人，最好的事情是看到所有团队成员都遵循您早日制定的原则。
因此，简而言之，这是我将要在正在启动的每个新iOS应用程序中再次使用的原理和框架的列表。
- RIBs架构（用于典型的面向UI的应用程序）：
–因为它允许应用程序的业务逻辑而不是UI树来驱动应用程序的体系结构；
–因为它可以实现下面设置的代码覆盖率和依赖项注入目标；
–因为它是一个简单的概念，所以使用它实际上并不需要框架，您可以通过采用仅包含4–5个协议的模式来开始使用它； - 基于初始化程序的静态依赖项注入：
–因为它使您的代码具有良好的隔离性，所以可以100％进行单元测试；
–简化了有关代码的推理；
–使其具有运行时安全性，并具有“如果可以构建，则可以工作”属性； - 反应性（RxSwift）数据/事件流，用于传递数据：
–因为从数据和事件流的角度考虑您的应用程序简化了其架构； - 单元测试涵盖100％的业务和演示/导航逻辑：
–业务逻辑类决定应用程序应导航至哪个屏幕，应向网络发出哪些请求以及应将哪些数据存储到本地数据库；
–导航逻辑很难在经典的MVC应用中进行单元测试，而这正是RIB闪耀的地方； - 快照测试涵盖了100％的用户界面：
–因为可以采用单元测试原则来测试UI是很酷的（例如，确保长标签能很好地包裹起来，并且不会以每种受支持的语言破坏屏幕的其余部分）； - UI自动化测试涵盖了关键的端到端用户旅程：
–创建和维护它们很困难，并且需要一些高级工具，但是它可以实现端到端的问答自动化，并最终获得巨大回报； - 用于以下方面的代码生成：
–模拟课程，以便您在单元测试中可以双打考试；
–网络服务和后端模型都是由singe跨平台IDL文件生成的代码，跨系统和团队共享，因为这可以确保这些系统可以可靠地相互通信；
–本地化字符串，图像和其他资源，以便有一个过程可以使您的字符串和资源井井有条，类型安全，并自动删除垃圾； - 仅允许使用RxSwift调度程序使用多线程，计时器，操作队列：
–使代码可以进行单元测试（不仅是原则上的，而且以可靠，快速且可控制的方式进行），并且单元测试也不易出错； - 所有UI均使用特定于领域的专用语言以编程方式创建（因此，没有XIB / Storyboards！）：
–以便对所有代码更改进行代码审查；
–从而使UI逻辑与业务逻辑分离，并避免使用Massive View Controller模式；
–这样就可以使用基于初始化的依赖项注入来实例化视图控制器和视图（并避免可选的拆包）；
–以便可以使用UI快照测试； - 自动翻译过程：
–因此，您不必手动上传字符串进行翻译； - 所有重要的代码更改，计划，详细的功能实现细节和推出计划，都将传达给所有团队成员：
–以便知识共享；
–建立反馈循环，使开发团队更加稳定和高效；
–因为这是我所知道的唯一流程，所以从2人小组扩展到1000+人小组非常好； - 我是否提到了强制性的预提交同级代码审阅，其中明确定义了团队之间的职责范围，并建立了自动分配相应团队的审阅者的规则：
–以便知识共享并保持编码规范。
定义了原则之后，哪种最基本的框架最接近我们？
- 对于主要应用目标：
– RxSwift，RxCocoa是Swift语言中最建立和支持的响应式库；
–用于网络抽象层的Alamofire；
–作为移动数据库的领域；
– SnapKit作为一种特定于域的语言，有助于在不使用XIB的情况下构建UI；
– RIB作为一种编程模式和一个备受好评的应用程序的业务逻辑构建框架；
–信封，用于在UIKit，Network，Realm上提供基于协议的抽象（当前正在使用它，从不同项目中提取可重用且细粒度的框架）； - 对于测试目标：
– Sourcery和SwiftMockTemplates代码生成模板，用于为单元测试生成模拟类；
– Swiftgen生成字符串和图像资产；
–缠绕以使翻译过程自动化；
–快速灵活地进行单元测试，以替代普通的旧XCTest；
–用于快照测试的iOSSnapshotTestCase。
上面的列表似乎包含了非常不同领域的框架。 那是故意的。 我希望框架提供高级抽象概念，而不是具体的构建基块，这就是为什么我不使用第三方图像选择器实现，而是在Alamofire和Realm中愉快地使用RIB和RxSwift的原因。 前者为应用程序增加了具体的专业化，并且依赖于（可能）维护不当的组件，而后者则增加了通用的编程概念，这些概念可以很好地协同工作并得到良好的支持。
和往常一样，我将不胜感激任何反馈或问题。
谢谢阅读！