Slack 工程师如何解决最常见的移动开发痛点

Slack 的开发者体验团队是由 8 个人专门负责的，该团队是为解决伴随组织和开发团队壮大而不断增长的成本问题。在 Slack 开发过程中成本最为高昂的部分，在于工程师需花费大量精力合并代码冲突、长时间的 CI 工作、片状测试和 CI 基础设施故障。

虽然可以让开发者们学习部分问题的解决方法，但随着团队的成长，所要花费的时间和成本是极不现实的。拥有一个特殊团队专注解决这类问题，不仅可以让开发团队效率更高，还能确保开发团队保持对产品成果的高度关注。

据估计，每百名开发者平均每年的成本约为 240 万美元，而合并冲突则是其中最大痛点，包括：Xcode 项目合并冲突、并发合并到主分支，以及漫长的拉取请求审查过程造成的。

Xcode 项目在代码合并时是出了名的冲突不断。为解决这一问题，Slack 工程师会使用Xcodegen来生成 YAML 文件对应的.xcodeproj 文件，后者是一种更为宽容的格式。

多次并发合并到主分支会造成更多的合并冲突风险，其他所有的 PR 合并都会暂停，直至冲突解决。对此，Slack 采用了Aviator，将所有 PR 排序一一处理。Aviator 并不会直接将所有 PR 合并到主分支，它会尝试先将主分支合并到一个开发分支上，如果这一步中主分支报错，Aviator 会拒绝 PR 并通知代码作者。

最后，为加速拉取请求的生命周期，Slack 工程师发现在 PR 任务、评论、审批通过以及构建成功的私信等加入定时提醒是非常有用的，包括不用离开 Slack 就能合并 PR 等功能。为实现这一切，他们创建了自己的 GitHub 机器人：MergeBot。

Mergebot 帮助我们缩短了拉取请求的审核过程，让开发者保持流动。通过节省每位开发者 5 分钟的时间，为百人开发团队一年内节省了 24 万美元。

值得庆幸的是，GitHub 也提供类似功能，就是“预定提醒”，尽管这一功能并不支持消息自身的一键合并。

优化 PR 及代码合并流程并不是 Slack 为改善开发者体验所采取的唯一行动。在另一个高成本的区域，测试和 CI 基础设施失败上，Slack 一方面执行平行测试，并根据 PR 差异只运行 PR 所需特定测试策略，另一方面，BuildKite确实对提高 CI 基础设施的稳定性有效果。

Slack 称，改善开发者的体验不仅能让开发者更高兴，也能降低整体开发成本。如果你对 Slack 实现这一目标的更多细节感兴趣，可以阅读原文。

原文链接：

How Slack Engineers Addressed Their Most Common Mobile Development Pain Points 

相关阅读：

斥资 277 亿美元收购 Slack，Salesforce 这一次的目标是微软？

Slack的原型制作流程

Slack的开发环境是如何演进的？