Power Automate - 代码审查的层次结构

差不多两年前，我写了一篇关于代码审查的博客(Power Automate 代码审查)，所以我觉得是时候更新一下这篇博客了。

查看了我的代码审查随时间的变化后，我提出了代码审查洋葱的想法。

代码审查就像剥洋葱，一层一层的，还会让你泪流满面。

这是一张代码审查流程图，你觉得哪些部分最重要？

代码审查一直以来都不太受欢迎，这一点大多数Power Automate开发人员不会看到其好处。这主要是因为代码审查实际上是为了风险管理，就像保险一样。它们是为了降低将来出问题的风险，比如第一个推行代码审查的人就深受其害，这个先驱者因此遭受了严重的后果。

代码审查其实并不像大多数人期望的那样主要是找 bug。代码审查不是用来找 bug 的，当然，如果发现了 bug 也会被标记。这主要是测试的工作。代码审查主要是为了三个目的。

1. 减少意外情况
2. 易读性
3. 性能和平台的稳定性

一起来看看吧

1, 减少意外情况

这是最接近于发现错误的方式，我们寻找的是任何可能引起不一致的地方，因此在测试中难以察觉。任何看似有效但不一定每次都可靠的设置或设计模式，任何设置或设计模式，。

一个很好的例子是“获取项目”功能的分页和阈值设置。但这可能会导致意想不到的结果，因为它每次只会返回最多100条记录。这意味着它可能在开发和测试阶段通过了，因为开发和测试可能没有充分进行压力测试，因此，这种问题可能要到生产环境中才会被发现。

2. 易读性 / 易维护性

关于任何项目来说，它终究会超越开发者的局限。开发者会继续前进，而这一过程需要不断更新。而这正是命名约定和标准模式发挥作用的地方，它们确保未来的任何人都可以查看代码、理解代码内容，并进行调试或改进。

想象几年后，当开发人员已经不再在团队中，出现了一个关键的错误。尽快修复这个错误至关重要，但当你打开相关代码时，你根本无法理解任何代码的作用，更不用说为什么某些地方出错了。

3. 表现 / 平台稳定

确保过程被优化是非常关键的，以保证它不会影响其他过程。这可能是最重要的原因，因为至少其他两个原因仅限于该过程本身。Power Platform中的每个账户/许可证每天都有API限制，每个动作，甚至一个条件，都是一次API调用。目前非高级许可证为6000次，高级许可证为40000次。因为限制不是针对单一流程的，这意味着不同的流程之间可以相互影响。

一个平台的稳定性的简单例子是API限速，如果你的进程会给另一个系统带来过大负担，可能导致其崩溃。

审查Power Automate流并不像想象中那么简单，有三种主要方式可以进行。

1. 代码审查的环境

这可能是最简单且最安全的方法。您会创建一个专门的审查环境来完成代码审查。这可以解决连接和共享方面的问题，只需要导出解决方案文件。一旦导入，审查者就可以查看所有组件，并记录任何发现的问题。

2. 代码审查中的安全审查角色

在这个方法中，我们使用系统定制器或者一个自定义的安全角色来进行审查。他们可以访问任何解决方案并完成代码审查，而且可以直接在流程中添加评论（但就目前而言，经典UI是最适合代码审查的界面）。唯一的缺点是，审查者被赋予了较高的权限，存在不小心编辑正在审查的流程的风险。一个只读权限的自定义角色是有效的，或者使用一个“即时”角色也是一个部分解决方案。

3. 代码审查工具

代码审查工具让你无需导入即可查看解决方案的内容。例如，AutoReview是一个例子。它们也可能包含一些自动化的测试功能，使得问题可以自动标记，无需手动查找。

有一个评分标准，因为并非所有的失败都需要立即修复。可能情况是“得不偿劳”，现在修复它可能需要太多时间，以至于会对投资回报产生负面影响。所以在我的代码审查中，我会分为三个等级：

红
紧急/关键的，这些需要在正式投入生产前解决
比如：硬编码密码

琥珀
这些是“效率最高时应该修复”的问题。通常在有新的更新或出现严重问题时会一并修复。
比如：有些操作未遵循命名规范

绿色
现在暂时不用改，但以后流程设计时要注意。这些更像是训练标记，当影响很小、没有必要更改时可以使用。
比如流程太复杂或太大，应该分解成更小的流程。

所以我们来谈谈实质的内容：

洋葱模型的关键部分是在Power Automate中需要关注的4层：

1. 解决办法
2. 连接
3. 例外情况
4. 设计

1. 解决方案

我们首先需要查看的地方是在解决方案中，确保支持流程所需的一切都到位。它涉及的内容有：

• 仅允许特定的缺失依赖项
  这取决于您的组织，比如我只允许自定义连接器和Dataverse表，但任何未批准的缺失依赖项都应被标出

• 环境变量
  不应有相同值的重复出现
  命名应该体现解决方案和描述
  不使用默认值（虽有争议，但这是意外行为的一个例子）
  如果环境变量太多，最好用对象变量来分组

• 连接引用规则
  每个连接应只出现一次
  遵循显示解决方案连接类型的命名规则

• 流程名称应解释其作用。

2. 关系和连接性.

连接是更高级别的东西，因为它们扩展超出了流动过程的范围。

• 不要硬编码密码或密钥

• 环境变量都用于除本地 Dataverse 数据表之外的数据源。

• 输入组的环境变量

• 确保所有敏感数据的输入和输出安全

• OneDrive/Excel 特殊情况，建议使用 Dataverse/SharePoint

• 触发设置
  触发流程后无条件执行
  仅在需要时运行，不会因为不必要的频繁调度或过于宽松的触发条件而运行

• 正确的方法
  请使用商业版本（Excel/OneDrive/Outlook）。

  只在特殊情况时才用HTTP版本

• 列表/获取项目
  分页和阈值设置
  在可能的情况下使用查询过滤器。

3. 异常管理

异常处理是确保异常情况被妥善处理，问题能够轻松发现的关键。这有助于减少支持团队的工作时间，减轻其负担。

• 主处理和异常处理范围
  这用于捕获所有错误，适用于全面错误处理。
  重试异常需单独处理，其他异常则应继续抛出

  RunAfter 不仅要在失败后超时，也要在超时后超时。

• 在异常处理中，始终要有一个失败标记来记录运行失败

• 包含失败的执行的表达式或链接地址，以便轻松在日志中找到该运行

• Result() 表达式及其筛选器或 XPath() 表达式

  在保存转换文件的过程中，应处理异常以删除文件。

• 一个名为flows的应用程序处理异常并将异常传递回去，这样App或父流程就能处理这个异常了

4. 设计.

这是最主观的部分，也是你在这里最容易出错的地方。如果代码没有很好地优化，只是这里或那里有个奇怪的 API 调用，这样的调整是否值得呢？

变量命名标准：我的偏好是 s字符串，b布尔，i整数，o对象，a数组。

• 动作命名规范
  保留动作的默认名称，并描述其功能

• 变量/组合 - 有效用例：
  所有输入都是全局的，因此不需要用变量来存储数据
  组合通过 API 调用来分离细节和使用位置，因此应该避免使用这种做法

  不要在条件判断中设置变量，用表达式来代替。

• 最小嵌套
  高嵌套让UI难以编辑和阅读流程
  条件内的条件可以通过与条件来避免，
  使流程更加简洁。

• 用于可配置值的环境变量
  对于可配置的值，建议使用环境变量，例如电子邮件地址和邮件内容

• 限制循环的大小
  避免嵌套循环，这会使 API 调用量急剧增加
  不要在循环内使用带有条件的过滤器，这会浪费不必要的 API 调用
  将非循环项移出循环，比如获取模板
  对于单行返回，使用 first() 或 [0] 获取

• 大小和复杂性限制
  过于复杂或过长的流程应拆分为多个流程，以帮助提高单元测试的效率、提高可重用性和改善UI响应速度。

• • *

代码审查总是对未来的一种投资，短期内的痛苦会换来长期的好处。拥有一个稳健的流程是关键（理想情况下嵌入到您的 alm/pipeline 过程中），以及易于获取的培训可以缓解短期内的不适。

演示文稿（点击这里下载）这里。需要的话可以点击这里查看，但请勿使用 Google Slides，因为格式可能会乱。我正在写我的第一本电子书，这本书会更详细地介绍这个过程，并包含示例，敬请关注它发布的消息。