导读：本文讨论软件开发过程中需要解决的代码审查流程中的关键。

我差点迟到，这是相当非常重要的点评。

人们不得不扪心自问，这是我们当初要设定的标准吗？我想大家都会同意事实并不是这个样子的。

代码审查——我们都需要确定什么:

• 我们要理解代码评审的目的

• 我们提供礼貌且可操作的反馈

• 代码符合操作标准

• 它没有明显的问题

• 我们保持开放的对话，要确保过程顺利

• 等等。

代码审查——对系统性能有何影响

随着我们的系统变得越来越复杂，并且团队总体上越来越多地转向持续集成和持续部署，我相信这一步将变得越来越重要。

代码审查——我们需要注意什么

• 它是否引入了 n+1 的挑战

• 缓存是否有潜移默化的好处

• 我们是否陷入僵局

• 等等。

虽然许多组织已经在其管道上运行了单元与集成测试，并且越来越多的组织也在添加 e2e 测试，

但很少有组织进行性能测试：这是我们在行业成熟时需要弥补的差距。

下面解释为什么我们也可以公开这些信息。

请先记住考虑下游影响和潜在的大规模问题。当你从外部方获取数据时，他们可能还必须查询其他的系统。 

有时，这些扩展问题可能会出现在意想不到的角落。  

以前，一些组织数据是以异步方式获取的，这最初并没有导致问题。然而，当我们进入新的用例时，我们很快就遇到了问题，因为开发者们进行了大量并行调用，而这些调用都需要完全相同的数据。

对于另一方来说，所有缓存都未命中，因此他们当前的系统也导致对这一基本信息的外部查找。 

当然，还有很多解决方案：

• 如果无法获取该字段，则与他们讨论并自行获取

• 首先进行一次调用来预热缓存

• 在基础缓存上对齐

• 等等。

但如果您不监控性能或进行负载测试，这种情况可能会很晚才被发现。仅仅触发一个调用不会触发此种情况。

一个主要挑战：时间

我们都经历过这类情况，需要解决任务单、需要进行代码审查、需要充实技术分析等……

这就是为什么让尽可能多的事情变简单是如此重要。 

对于本地分析，我们可以使用 IntelliJ IDEA 插件使遥测数据更接近开发人员流程。  

如果我们使用 GitHub，我们可以利用两个新的 Digma 进行操作。

* digma-ai/digma-actions/instrument 

允许我们使用 OTEL 数据向我们的应用程序添加仪器，并将捕获的数据发送到 Digma Analytics Engine。

* digma-ai/digma-actions/assert-no-issues 

可用于验证没有被忽略的问题是我们的拉取请求的一部分。

https://github.com/digma-ai/digma-actions

绩效影响：我们需要弥补的差距

我认为这个差距应该在开发期间就应该被弥补或完善——这也是为什么在本地执行代码审查时可以使用的工具（如 Digma）非常方便的原因。

如上所述，虽然许多组织肯定已经在其管道上运行了单元和集成测试，而且越来越多的组织也在添加端到端测试，但很少有组织还包括性能测试：随着行业的成熟，我们需要弥补这个差距。

本文由高级软件工程师兼 Java 顾问Simon Verhoeven 撰写，发表于 Digma 博客，他目前专注于云质量和可维护性。

编译：场长

作者：Simon Verhoeven 

来源：https://x.com/Simon_Verhoeven