在我加入乐天公司目前的团队之前，我并没有真正想过我一直在为我的移动应用程序添加的SDK（又称库）。添加第三方代码或SDK只是为了在更短的时间内获得UI特性或功能（如崩溃报告），并且在理论上风险较低。
然而，在过去的几年里，在乐天，我想了很多关于如何构建SDK的问题我也应该这样做，因为提供高质量的移动SDK是我们团队的使命。
大多数提供内部SDK的公司的团队似乎要么提供一个涵盖所有内容的通用SDK，要么可能提供一个认证SDK和一个功能XSDK。另外，根据我在面试时的聊天记录，他们所谓的SDK往往只是在同一个源码库中的独立模块，没有适当的部署。这绝对没有错，但很难扩展。
在MTSD的SDK团队中，我们有长期的和较新的产品，这些产品加起来的数量相当大--为了给你一个概念，去年的一个主要焦点是试图将我们支持的产品从目前的16个减少到不到10个。
我们的许多SDK是稳定的长期产品，没有固定的交付时间表，但我们的团队仍然需要在需要时维护和发布这些产品的新版本，有时是在相对较短的时间内。我们的团队是相当小的（每个iOS/Android有2-3个开发人员），所以除了紧急维护/修复错误的任务，我们尽量在任何特定的时间集中在几个产品的积极开发上。但由于情况的发生，我们需要对优先级的变化做出反应。
在这篇文章中，我想着重介绍一下我们（我想主要是）如何在乐天规模上实现构建和提供高质量的移动SDK。
我们最近在GitHub上 公开了我们的移动SDK开发指南我们在团队中使用这些指南来保持质量，帮助新的工程师入职，并与其他乐天团队分享我们的方法，他们在构建自己的SDK时也会向我们征求意见。
这些指南有点（好吧，非常）枯燥，所以这里有一张我为内部技术社区演示制作的图片，以强调（通常是隐藏的）团队努力和持续交付多个SDK的各个方面同时保持高质量和最低的开销。
让我们来探讨一下隐藏在冰山表面下的东西吧!
为了给应用程序开发人员提供良好的产品体验，我们努力使我们的SDK成为:
- 高质量
- 同行评审的代码
- 在每一次PR/合并中通过CI运行自动单元测试
- 易于使用
- 简单、流畅的API
- 优秀的用户文档
- 响应的开发者支持
- 易于整合
- CocoaPods/Gradle依赖性
- 以零到几行的代码进行配置
- 通过自动化部署
- 最大限度地减少工作量
- 最大限度地减少人为错误的风险
- 设计/架构合理
- 限制依赖性
- 只暴露必须暴露的东西
- 松散耦合的组件
- 稳健和安全
- 适当的版本管理
- 遵循语义版本化
- 在不同平台之间保持一致
- 相同的API接口
- 相同的高层架构
- 可长期维护
- 达到V1.0版本后保持稳定
- 至少6个月的寿命结束通知
我们的团队心态是持续改进的。由于SDK开发的性质，我们不可能总是像应用程序团队那样快速前进。在我看来，这主要是一种好处，使我们能够想出可持续的技术和流程改进。
我认为我们的团队已经达到了一个很好的成熟度，但总有一些方面我们可以改进。例如，在去年第二/第三季度，我们使用bitrise CI（专门为移动团队设计）进行了PoC。PoC是成功的，在第四季度，我们把所有的SDK iOS pull request CI从Jenkins/Travis迁移到bitrise。
我们还可以（并打算）改善我们内部SDK的文档,iOS上的文档是用Doxygen生成的。它们有点老派（虽然很实用），需要改版。我们的开源版本，例如应用内消息，有更好的文档，由Jazzy生成并托管在GitHub Pages上。
使用Swift构建你的iOS SDK可能是最好的，因为它的安全性、简洁性和可读性比Objective-C好，关键是它已经获得了模块和ABI稳定性，可以在不同的Swift版本之间兼容。
ABI稳定性允许用不同版本的Swift编写的程序存在于一个共享的运行时中，而模块稳定性允许你在一个可能使用另一个版本的Swift的项目中使用不同版本的Swift编译的框架。
我希望你觉得上面的文章很有趣，也许很有用。如果你想讨论关于构建移动SDK的任何问题，请评论或联系我们。
