圆桌代码审查实践

[ashammi228]

在 Lineate，我们致力于提高整体开发质量。本着这一精神，我们最近开始实施圆桌代码审查会议，即一对一的代码审查，不仅可以确保代码质量和准确性，还可以让工程师全面了解项目。我们相信这种做法将有助于在不同级别的工程师之间传播知识，促进引人入胜的团队建设对话，并从长远来看提高代码质量。

团队代码审查实践
在日常工作过程中，每个团队成员都可以在共享空间（例如带有特 女性数据库 定标签的 Slack 频道）提交问题或建议。这些评论和问题并不紧急，但被视为感兴趣的话题，旨在提高整体项目质量。团队负责人和高级技术人员会审查这些主题，并按相关性和重要性顺序选择要讨论的主题，然后提前宣布这些主题并邀请团队参加会议。

团队建设
一个功能的正常代码审查流程通常只涉及一到两名审查人员，因此团队的其他成员可能不知道作为每个功能的一部分实施的技术解决方案。一方面，这是对资源的合理利用，因为我们不应该浪费每个人的时间来审查每个小功能，所有这些小功能都与给定项目中的数百个其他功能相似。另一方面，这种方法会丢失重要的大更新，这些更新可能会对整个项目开发产生重大影响，而其他团队成员可能会对具体实施产生积极影响。

与常规的代码审查不同，圆桌代码审查会议涉及当前团队的所有人以及可能在该领域拥有相关经验并有兴趣分享的其他项目的工程师。

除了软件开发人员之外，团队领导还会邀请管理和 QA 工程师，他们可以就解决方案的技术实现和业务需求方面提供有趣的想法。

这样，每个人都可以提出自己的想法和意见，并立即得到反馈。这种方法还允许人们就他们不熟悉的解决方案提出问题。

圆桌代码审查会议在我们的公共区域引发了关于不同项目的热烈、面对面的讨论，使每个人都更加投入。一些主题（如 RHEL9 迁移、Java 21 迁移、Docker 配置的常见陷阱、Ansible 最佳实践和 Solr 9 的新功能）引起了人们的极大兴趣，以至于它们导致了整个公司的规模更大的演示。

此外，我们将这些会议的所有要点和见解汇总到一份文件中。这已成为新团队成员的实用指南，帮助他们快速上手。

最重要的是，这些讨论极大地增强了我们初级工程师的信心。他们更愿意提问和参与，这有助于他们更快地融入团队。

代码质量改进
这种方法使我们能够将更多审阅者的能力集中在最重要和最具挑战性的功能上。因此，我们可以从那些在正常代码审查过程中无法看到具体解决方案的人那里获得更多意见。

此外，从事其他项目但任务类似的人也可以针对该主题提供相关建议，帮助分析其他客户如何解决类似问题，并根据他们的经验调整解决方案。因此，我们正在将学到的经验教训传播到整个公司。

例如，在最近的一次圆桌会议中，在审查过时操作系统的问题时，另一个项目的工程师提出了两个新选项。他建议迁移到另一个受支持的操作系统，甚至购买操作系统分销商的扩展支持，而不是迁移到当前操作系统的较新版本（这本来会很复杂）。由于其他项目最近也遇到了同样的问题，花了一些精力进行选项分析，甚至有经验可以取得成果，因此该团队可以重复使用这些解决方案。

还有两个积极的副作用有助于提高代码质量：

我们可以为其他团队成员提供建议，帮助提前避免一些错误。

我们可以比正常的代码审查期间更广泛地讨论解决方案，并且在从一个点移动到另一个点时，找到一些未经审查的代码改进想法。

例如，在一次会议中，一个团队讨论了如何为其基础设施解析网络资源。当他们讨论本地主机文件、DNS 解析、AWS Route 53 和本地 Nginx 配置时，他们找到了一种更好的方法来设置对客户服务的访问，并且我们能够消除对 AWS VPN 服务的使用及其相关成本。

结论
Lineate 的圆桌代码审查会议通过促进各个团队之间的全面了解，显著改善了我们的项目开发流程。这种做法不仅确保了代码质量，还通过让来自不同项目、管理和 QA 团队的工程师参与进来，整合了更广泛的视角。这些讨论对于传播知识、促进动态团队建设以及根据集体见解和共享经验改进我们的技术解决方案具有重要意义。此外，通过鼓励如此多样化的意见和协作，这些会议为创新解决方案铺平了道路，这些解决方案可以极大地有利于整体项目交付，推动我们的项目取得更具创造性和更有效的成果