人是任何企业的主要价值。 整个过程的成功取决于人们之间的沟通方式，他们如何共同实现目标以及团队合作。 不断磨练技能，流程和工具可以使您更高效地工作。
我们在市场上正在努力为我们的用户尽快提供新功能。 为此，我们不断研究我们的流程并优化任务的所有阶段。 今天，我们将向Habr的读者介绍其中之一的优化，即代码审查过程。
首先，您需要想象一下我们采用了什么样的开发流程：
同一件事，只是一点一点地用言语表达：
- 开发人员承担任务。
- 使她。
- 填写Github并打开PR。
- 通过代码审查。
- 收集演示架并将其交给测试人员。
- 测试人员检查演示台。
- 已验证的任务在发布中收集。
- 在发布中进行测试。
- 产品上的布局。
- 战斗中的最终测试。
根据职责范围，任务分为以下步骤：
1-5-对开发商的责任；
6-7-测试人员的责任；
8-10-发布主的责任。
因此，他们开始分析花费我们最多时间的事情。 幸运的是，有内部分析工具。 每个人都需要花费最长的时间，当然是开发过程本身（状态为“工作中”）……事实就是这样。 但是片刻最让我们感到惊讶。 审查的平均持续时间为两个星期！
步骤1.解析PR
开始研究请求请求后，他们立即面临一个非常有趣的事实。 原来，我们有一个未完成的请求请求的巨大公墓。 这些PR的大多数作者不再为公司工作，但他们的遗产仍然存在。 谁从未见过恐龙，他们在这里：
这些拉取请求增加了噪音，并干扰了正确的代码检查时间分析。 我们以冷静的心态关闭了它们。 剩下的只是重述时间。 但是它仍然在2-3天的范围内。 不好
第2步：与布朗纳一起拆卸
Reviewer是在Yandex中开发的系统，该系统召集了两个具有可变代码专业知识并考虑休假和缺勤的随机人。 对每周PR的分析显示，一群人不断地拖出代码审查。 在采访了同事之后，我们发现了我们过程中的另一个问题。 同事们抱怨说，他们每天收到的嫉妒请求太多，他们根本没有足够的时间进行主要工作。
这与我们的指标不一致：每人每天一两个PR。 该研究导致了Github，我们在那里有一个独立的审阅者团队。 该团队已有数年未更新。 从那时起，员工人数增加了一倍，但新人中没有一个被纳入审核员团队。 换句话说，一半的团队根本没有参加代码审查！ 纠正了这种令人讨厌的误解。
步骤3.扩展工具
在这个阶段，我们试图简化我们认为已经很简单的审阅者的工作。 前端工具库中包含以下工具：
- 代码样式检查器；
- 试运行；
- 公关本身的各种书呆子检查；
- 修正主义者
- 在邮件和任务跟踪器上发出警报。
似乎一切都在那里。 参加并复习！
事实证明第一件事是错误的：不同存储库中的代码审查过程不同。 我们进行了统一，同时证明了通过Github界面粘贴标签可以方便地搜索PR。
他们注意到的第二件事：邮件不是快速报告代码审查状态的最佳工具。 为了不分心，许多人每天都要解析他的邮件数次。 信使是完全不同的事情。 对Messenger中的消息的反应要高得多。 并且决定将机器人与我们的Messenger相连。 该漫游器会为拉取请求的作者发送有关代码审查状态的警报，并鼓励人们进行审查。 很舒服
步骤4.第一个SLA
与行动2和3并行，我们开始与员工紧密合作，并解释说代码审查与任务本身是分不开的。 他们解释说，开发人员有责任将其带到“已验证”。 而且，责任不仅对同事，而且对用户！ 快速将功能交付销售-这就是我想要实现的目标。 团队对改进过程表示同情。
在这个阶段，理想代码审查的第一个想法诞生了。 当然，每个人都希望它在5分钟内完成，但这并不总是可能的。 考虑到我们拥有一支跨区域团队（时差为四个小时），我们同意我们的SLA为一天，即 24小时 已向所有员工宣布了此SLA，并揉着手开始等待结果。
但是情况没有改变。 在最好的几周内，一半的拉取请求适合1天。 其余的都给他了。
我们有一个小脚本，用于评估PR上的时间代码审查。 我们开始每天将所有公关归咎于他们，以求“落伍”。 几乎每天都有一包这样的东西。
解析它们花了很长时间。 大多数情况下，脚本本身不诚实地计算了审核时间。 他没有考虑到某些PR是在工作时间以外创建的（是的，一些有胆识的人喜欢在晚上工作一两个小时，来找我们工作！）。 所有这些告诉我们，拉取请求监视工具不是最有效的，因为它们是不诚实的。 我必须找到新工具。
步骤5. SLA跟踪器
帮助来自他们没有等待的地方。 来自Tracker的同事宣布了一件了不起的事情：现在您可以在Tracker本身中安装SLA。 此外，您可以完全不同地配置它。 任务中的某些事件会打开某个计时器。 对于某些事件，它可能会暂停。 并停止在某个事件。 是的，这就是我们所需要的！
他们立即对文档进行了详细的研究（顺便说一下， 这里是 ），并设置了我们的队列（由于存储库的存在，所以有几个队列）。 我们将计时器设置为在切换到“需要代码查看”状态时打开，并在切换到其他任何状态（“有评论”除外）时结束-当计时器消失时，计时器暂停，即 并没有浪费时间。
计时器考虑到工作时间和日历也很酷！ 我们设置将9h分配给代码审查，即 一个工作日。 在这种情况下，警报会在开始2小时后触发，或者如果九小时的截止期限被打破，则会触发警报。 结果是一种诚实的监控。 首先，为了进行实验，我们打开了计时器，收集了一堆错误并导出到Tracker。
值得注意的是，仅对计时器本身实现后创建的任务启用了计时器。 因此，看不到即时效果。 但是已经在现阶段开始了积极的动力。 一个月后，当带有计时器的新票流开始挤出旧票时，我们得到了效果。 值得注意的是，代码审查的大概时间集中在提醒消息的区域，即 分别是2h和9h。
在撰写本文时，我们有415个计时器已启动的任务。 其中有29个超出了9小时的边界。 尽管，如果您仔细观察，您还将遇到这样的任务，它们的代码检查在下一小时内完成。 如果我们也丢弃它们，那么还有17个任务。 大约是4.1％！
结果。 武士不断磨刀
回顾和回顾我们的所有行动，可以得出一个结论-所有手段都是好的。 我们所有的步骤都达到了预期的结果：超过92％的拉取请求开始满足我们的SLA ！ 任务越来越少，代码审查更快。 慢慢地，渐渐地， 75％的代码审查开始适应5个小时 ！ 而且改进的动力仍然是积极的。 除了数字指标，我们还开始从分包商那里获得更多积极的反馈。 团队对整个过程做出了反应，这一事实让我们更加满意。 甚至诸如代码审查加速之类的过程也使团队更加团结。 每个参与者都开始理解他比其他人承担的责任，因为快速查看代码可以使我们更快地使用户受益。
当然，9h不是最终的梦想，而是成功的梦想。 但是，我们不打算停止。 我们将继续监督代码审查过程，并解决员工面临的所有技术甚至心理问题，以使我们的过程尽可能高效，同时使团队感到舒适。
问与答。 如果...？
问 ： 如果我认为他们在看着我怎么办？ 这个计时器是做什么用的？
答 ：我们不是专门针对某人，而是针对整个过程进行监控。 拉取请求有两个方面：作者和审稿人。 如果审稿人拖出支票，那么作者将受苦。 另一方面，立即将检查员从工作中撕下来也是不人道的。 必须找到一种平衡，使双方都感到舒适。 不需要计时器来惩罚某人，而是为了记录所有偏差。 这些偏差中的大多数并非是由于审阅者的过错，而是由于技术问题的错。 面临的挑战是解决这些问题。 这样别人就不会遇到他们。 不断自我完善
问 ： 如果有复杂的PR，有100500多行代码，并且有“更改字母”怎么办？ 正义在哪里？
答 ：是的，这是真的。 在进行标准代码审查时，我们只是沿上限进行，即 复杂PR的代码审查应适合SLA。 但是，与此同时，我们没有将所有人带入这些界限的目标。 尽管一天的时间都中断了，但我们总是很同情提出请求，在其中进行了生动而有用的讨论。
我们已针对故事点制定了SLA等级的计划。 例如1SP-1h，3SP-5h，5SP-2d。 幸运的是，Tracker已经能够做到这一点。 我们还没有为此做好准备-我们还有很长的路要走。