iOS @ Over：成立平台团队
所有扩展团队都面临的挑战是处理越来越多的技术债务和性能问题。 团队中只有几个人，在重构和知识共享上进行协调就更容易了。 随着团队的扩大，协作和沟通变得越来越复杂。 一旦这些团队开始更快地行动，放慢速度并处理越来越多的技术债务就变得更加困难。
在本文中，我们将说明Over团队内部发生的情况以及导致iOS平台团队创建的原因🚀
a扩展团队的裂缝
随着我们团队的扩展，我们的代码库也是如此。 我们主要在Swift中进行开发，这对我们的总体构建时间有很大的影响（希望这可以改善WWDC🤞）。 Buddybuild上的构建服务器大约需要20分钟的时间来构建并运行我们对Pull Request的所有测试。 干净构建Over可能最多需要3分钟的时间。 这些时间每天都会加起来，当我们开始注意到如何切换到Slack或等待时浏览网页时，情况会变得更糟。 等待构建时进行的所有上下文切换确实损害了我们的生产力。
我们经历的另一个痛苦点是不断增加的技术债务。 一个这样的例子就是我们用团队替换了圈子功能。 这是一个很大的重构，也已实现为功能标志。 这意味着Circles和Teams并存。 一旦我们最终发货，团队就继续为团队提供支持，并且无法真正证明删除旧代码所花费的时间是合理的。 毕竟，将有意义的功能交付给我们的用户是我们的首要任务。
以上问题只是众所周知的冰山一角。 一旦我们退后一步，很明显，我们需要一支专门的团队来完成产品工作，并且可以专注于帮助我们的iOS团队更加成功。 我们确定了我们团队中的一个人Jamie Raad，他愿意潜入创建平台团队并定义工作量和优先级工作。 让我们看看它是如何下降的……😃
✍️定义我们的平台团队
平台团队的存在是为了确保面向用户的功能团队的持续成功。 由于平台团队不受功能工作和产品截止日期的束缚，因此可以自由地关注更广泛的挑战，这些挑战会阻止团队更顺畅地进行运输或提高生产力。
这是我们作为团队优先考虑的任务列表，我们应该从以下几项开始：
- 缩短构建时间（在本地和在Buddybuild上）。
- 研究新的崩溃报告工具。
- 从应用程序中删除领域。
- 来自各个部门的临时请求。
平台团队还负责倾听团队的技术需求，并研究新的和改进的API，以协助软件交付。 拥有一支专门的团队还意味着我们有资源来调查诸如难以复制的模糊错误，图像预加载机制以及可重复使用的通用提要的方法。 这些只是平台团队可以改善我们工作方式的一些现成示例。
👀第一组结果
随着平台团队的建立和准备就绪，我们开始了第一个挑战： 构建时间 。 此处的目标是尝试确定构建哪个框架花费的时间最长，以便我们可以准确地确定优化的地方。 最终，能够将构建时间减少至少50％将是一项巨大的成就。
为了获得结果，我们遵循将不同的诊断选项传递到编译器的这些准则。 我们通过了-driver-time-compilation和-Xfrontend -debug-time-compilation 。 这里有更多关于他们的信息。
xcodebuild -destination 'platform=iOS Simulator,name=iPhone 8' \
-sdk iphonesimulator -workspace Over.xcworkspace \
-scheme Over -configuration Debug \
clean build \
OTHER_SWIFT_FLAGS="-driver-time-compilation \
-Xfrontend -debug-time-compilation" | \
tee profile.log
我们决定不使用debug-time-function-bodies因为我们只是在寻找总体构建时间，而不是每个函数的时间。 然后，我们编写了2个脚本来处理每个选项的输出，最终使我们可以了解构建时间。
脚本结果
我们的脚本读取了构建日志并计算了每个CocoaPod中所有Swift文件的总时间，我们忽略了Over中的文件。 以下只是罪犯中的一小部分
RealmSwift
Execution Time: 13.662400000000002
Wall Time: 38.39059999999999
Unbox
Execution Time: 12.765
Wall Time: 30.538700000000006
Alamofire
Execution Time: 9.7638
Wall Time: 26.3308
FacebookCore
Execution Time: 8.8349
Wall Time: 24.321099999999994
AlamofireImage
Execution Time: 3.0501
Wall Time: 10.8478
FacebookLogin
Execution Time: 1.3653999999999997
Wall Time: 5.8422
KeychainAccess
Execution Time: 1.2674
Wall Time: 1.9256
OverLogging
Execution Time: 0.5084
Wall Time: 1.1639
CocoaLumberjack
Execution Time: 0.3282
Wall Time: 0.4215
有了这些知识，我们知道我们首先要做的。 在将Realm确定为构建速度最慢的第三方框架之后，我们想测试不使用CocoaPods手动添加和配置它的影响。 值得庆幸的是，Realm提供了一个预构建的二进制文件，您可以将其手动添加到项目中。 预先构建的框架的优点是Xcode在构建项目时不会对其进行编译。 与CocoaPods相比，这可加快构建过程，后者在每次清理或删除派生数据后进行构建时，都会构建并编译我们的框架。 这一更改对我们的构建时间产生了巨大的影响。 我们看到减少了大约100秒！ 🎉
缺点之一是手动添加框架时涉及多个步骤。 有用的是，Realm提供了一个现成的已编译框架，并非所有库都可以这样做，在这种情况下，我们必须自己编译它们。
由于这是一个繁琐的过程，因此如果继续下去，迦太基将是一个很好的替代依赖管理器。 好处是它将为我们编译框架，并提供1个脚本从所有框架中剥离体系结构。
尽管如此，以上练习证明了检查我们的构建时间的重要性，并且有切实的方法可以改善它们。 我们的目标是将构建时间减少50％，我们做到了。 就目前而言，这已经足够了，我们还有一些非常有趣的机会可以减少将来的使用。
Next接下来是什么？
平台团队将继续在积压的产品中尝试构建时间。 老实说，我们迫不及待地想看到我们在新团队中取得的成就。 从研究新架构之类的大事到我们一直难以修复的小错误（看着您iCloud⛅️）。
一个真正令人兴奋的探索途径是这样的团队在培养新人才方面的潜力。 由于他们无需进行功能工作，对于初级开发人员来说，这是一个加入并专注于探索代码库并解决没有严格期限的问题的好地方。
想听到更多吗？ 确保在Medium和Twitter @ EngineeringOver上关注我们
我们正在招聘！ 结束工作