Ostorlab 的 Fix it! 实践

Ostorlab 的 Fix it! 是我们最成功的工程实践之一。这是一项竞赛形式的活动，持续一到两周，团队成员比拼谁修复的缺陷最多。

虽然参加 Fix it! 通常是自愿的，但在 Ostorlab，我们确保整个团队都参与其中。这体现了我们团队协作、力求让工作成果尽可能没有缺陷的决心。

为了进一步说明我们采用这一实践的原因：在 Ostorlab，我们通常以项目模式运作，组建 2 到 8 人的小组来开发功能、修复重大缺陷或清理技术债务。虽然影响严重的缺陷和问题通常会立即得到处理，但许多较小的烦人问题却始终排不到优先清单的前列。 Fix it! 通过将所有不符合立即修复条件的问题标记为 fixit! 来解决这一点。

如果您有兴趣在自己的团队中应用同样的理念，以下是我们总结的一些经验：

• 时长：Fix it! 的时长在一到两周之间变化，时间过长会让人不堪重负，而一周又太短。修复缺陷可能令人精神紧绷，因此确保分配的时间合理至关重要。

• 跟踪：此外，在活动期间，我们使用一个内部平台来跟踪修复情况，并通过排行榜展示随时间推移的进展，这让活动变得有趣，也激励每个人全力以赴。

• 积分制度：重要的是平等对待所有缺陷，避免为缺陷建立积分制度。这有助于避免争论某些缺陷价值更高还是更低，让事情保持简单。因此，简单的缺陷通常会最先被清理，只有较难的缺陷留到最后。 在 Fix it! 活动期间，修复之前或修复过程中可能会发现新的缺陷。例如，在上一次 Fix it! 中，我们从 161 个缺陷开始，清理了 142 个，最后还剩下 132 个。虽然这笔账算不平，但这有助于我们对平台进行详尽的测试，并发现一些可用性上的小问题，以便在修复缺陷的同时一并解决。

• 代码审查：由于 Fix it! 的激励机制侧重于修复尽可能多的缺陷，代码质量往往会被放在次要位置。 拥有一条包含代码规范检查、类型检查、单元测试覆盖率以及完善代码审查流程的强大 CI/CD 流水线至关重要，以免引入的缺陷比修复的还多。

• 周末：如果 Fix it! 持续超过一周，我们会确保周末不进行修复工作。这样可以保证每个人步调一致，并且有机会享受个人时间，而不会感到必须工作。

• 收尾：在 Fix it! 结束时，我们会分享结果，并讨论进一步改进的方法。我们还会重点介绍一些有趣的方面，例如修复起来最酷的缺陷，或出乎意料地难修的缺陷。 我们还会分享经验教训，这些经验有助于指导未来的技术栈决策或系统设计选择。通过分享我们的经验，我们可以找出流程中可以改进的地方，并在未来避免类似问题。这有助于我们持续提升工作质量，确保我们的系统更加稳健可靠。