关于代码审查 ： “我觉得它看起来不错”！
导读：本文讨论软件开发过程中需要解决的代码审查流程中的关键。
我差点迟到，这是相当非常重要的点评。
人们不得不扪心自问，这是我们当初要设定的标准吗？我想大家都会同意事实并不是这个样子的。
代码审查——我们都需要确定什么:
我们要理解代码评审的目的
我们提供礼貌且可操作的反馈
代码符合操作标准
它没有明显的问题
我们保持开放的对话，要确保过程顺利
等等。
代码审查——对系统性能有何影响
随着我们的系统变得越来越复杂，并且团队总体上越来越多地转向持续集成和持续部署，我相信这一步将变得越来越重要。
代码审查——我们需要注意什么
它是否引入了 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
相关阅读：
微信扫码关注该文公众号作者
戳这里提交新闻线索和高质量文章给我们。
来源: qq
点击查看作者最近其他文章