如何优雅的编写逻辑？Microflow 的最佳实践指南这是我们在项目中开发 micoflow 时采用的一些最佳实践的体验

颜色的使用

对我们R&D 团队来说，可以通过不同的颜色来立标准，这样开发人员可以通过microflow一目了然地识别某些动作和步骤，而不是通过详细的一步步阅读。以下是我们如何使用颜色：

如果不进行定义，这四个动作会像其他所有动作一样默认为标准蓝色，但为了需要一目了然的看懂它们，我们的定义非常有意义。

此外，我们不想为每一种动作类型都进行颜色的定义，只希望将开发人员的注意力，关注到流程中的关键步骤上。

我们也可以使用红色来区分具体是错误的消息，但我们不会对此进行标准化，不需要进行太复杂的定义，这样会增加识别的困难度。

Java Actions 和 Error Handling 之类的东西已经在动作上有了符号，所以他们很容易被识别。

我们的经验告诉我们，代码应该写成模块并且保证大小、否则会很难理解和难以维护。当我与初级的开发人员一起审查代码时，我看到的最常见问题是他们试图创建这些从头到尾完成业务逻辑的巨大微流。

该代码虽然可以完成工作，但它是维护和遗留问题的噩梦。您希望将处理的逻辑的每一部分分解为更小的业务逻辑段，以便： a) 如果您想要进行更改，则不必重新测试数十个相关微流操作， b) 如果您决定更改逻辑的那一部分，您不必重构整个总体事务，只需重构其中的一部分。

其实，也正是这种思想将微服务架构推到了风口浪尖。

例如，开发人员需要在用户单击“保存”时创建业务逻辑。该业务逻辑需要：

针对这个场景，最佳实践方法是构建至少 6 个微流：

一个用于每个子事务，

一个总体微流按需要的顺序调用每个微流作为子微流。

在这些步骤中的每个步骤中，您可能还会构建多个子微流。

例如，“同步”步骤可能有一个用于获取 API 配置数据的子程序，一个用于暂存数据以映射到调用的子程序。

一个用于调用 api 的子程序。

一个用于处理错误的子程序……你懂的。

使用这种层次结构方法，您现在可以根据需要在您的应用程序中重复使用单独的代码片段。

如果你需要为另一个进程调用那个Sync API，你不必从头开始，只需调用相同的API Config，API Call，Error Handler等，并根据映射完成对应工作。

我们可以进一步分析这个场景，将其中一些事务步骤设置为事件处理程序，但这是针对不同主题的。

这一直困扰着开发人员，包括我自己。即使在这样做了数千次之后，我可能会忘记立即使用检Retrieve 的数据是否为空，并且不可避免地，无论这种情况多么不可能，UAT 测试人员或生产用户都会导致Retrieve数据为空。

因此，作为最佳实践，每当您有“Retrieve”时，立即使用 Exclusive Split 跟踪它并检查是否为 Empty 并处理它（记录它、发送消息、通过电子邮件发送……无论如何，要处理它）。这样做只需不到一分钟的时间，并且可以避免您以后的痛苦。

特别是集成！由于网络流量问题，API的网络集成必定会带来不稳定的问题。如果超时、丢失数据包、证书过期……您将遇到需要处理的错误。如果我在微流中看到一个 Java Action，我必须看到一个错误处理图标和流设置，最好是记录堆栈跟踪和任何其他相关数据。

在你的变量名前放一个小写的“v”，这样在编写逻辑时很容易找到它们。无论是 Xpath 还是 Function，您都可以按 CTRL+C、$v 并立即看到您的变量。

这个有点简单，但经常被忽视。可视化代码方法应该足以记录代码，但有时我们会在一个步骤中隐藏很多逻辑。例如，Exclusive Split 可能有复杂的逻辑，您无法用一两个词来概括它。

将注释附加到拆分并写下您的姓名和日期（以便未来的开发人员知道谁知道该操作）并描述正在发生的事情。这也用于您正在更改大量属性并且代码可能隐藏在每个属性上的更改对象。

总结正在发生的事情，以便业务用户一眼就能理解流程图。

我们几乎都是从上到下、从左到右阅读。因此，您的代码流应该类似地流动。如果您有错误处理程序或Exclusive Split，请确保逻辑保持事务向右流动并向下进入次级和超越拆分路径。

这个有点有争议，因为我看到人们用垂直向上的拆分来分叉他们的代码，但作为最佳实践，我建议您避开它，以便 Microflow 始终以开始（绿色圆圈）为中心流的最高点和最左边。

这是我们在项目中开发 micoflow 时采用的一些最佳实践的体验。当然还有更多的最佳实践，但这些是很重要的规范和实践，可以让我们获得许多不同项目的最佳实践。当然，如果您不同意我的任何内容，请发表评论，让我们一起来努力为正在和未来将要使用西门子Mendix 的应用程序开发人员来构建参考指南！