成功的连接器： 最佳实践和实施策略

连接器的最佳实践始终是强制采用基于规则的方法，并将任何异常作为后果或基于规则的耗尽来处理，而不是从基于异常的方法开始。

基于例外的方法很有吸引力，因为它重视人类的选择和对当前流程结构的保留。 但它描绘了一个向量，指向一个在长期内没有好的替代方案来扩展和维持健康流程的地方。 在这方面，从考虑例外而不是规则开始是一个错误，我们不惜一切代价避免。

简而言之，短期收益换取长期痛苦。与我们合作的大多数组织都有一个共同点：他们寻求当前流程保留。 当技术被寻求时，它意味着要拥抱当前的流程，而不是在流程限制和效率之间查找一个折中点。

我们的连接器是一种将内容从存储库传输到BWX然后再传回的方式。 虽然我们理解偶尔需要为基于连接器的工作挑选一个或另一个文件，但连接器的最佳实践是遵循基于规则的方法，而不是手动方法。

手动方法的诱惑解释

手动方法很诱人，因为它们不需要任何流程更改。 人们可以浏览他们想要翻译的确切文件，并使用连接器启动翻译项目。 手动方法的问题在于它不可扩展、不可持续且可预测（难以改进）。

这就是为什么我们只有在用尽了将连接器行为拟合到基于规则的行为的所有可能性之后，才探索手动方法。处理异常是必要的，但你不能通过异常进行设计。

成功的产品及其各自的实施基于涵盖最大可能百分比的用例的规则。 未覆盖的用例需要仔细评估，以探索解决方法和解决方案，以便在建议的范式中对其进行实施。

这是一个例子：客户A有一个基于时间表运行的连接器，但有时他们有需要非时间表运行的项目。 以下是有关如何解决此问题的几种不同选项：

1. 手动请求我们的支持团队进行非计划运行
2. 使用我们的 CLI 请求非计划运行
3. 创建一个比典型计划更频繁轮询的非周期性分支/目录，以便处理紧急工作。

这是另一个示例：客户端 B 用于挑选文件以启动本地化过程。 与其延续手动方法，大多数 cherry 拣选流程确实遵循可以逆向工程的行为。

将这种逆向工程推向极限的努力总是值得的。 如果你一开始采用手动方法或专注于通过UI从一开始就覆盖例外情况，这将成为一个削弱的拐杖，而不是程序加速器。当我们想到连接器时，我们总是想到自动化。

这就是连接器驱动的真正流程效率。 导出和导入项目在涉及连接器时是一个小的收获。 真正的收益围绕着业务规则以及它们产生的可预测性和治理。

问题在于，如果您通过例外进行设计和实施，自动化永远不会真正成为一种选择。 根据定义，自动化需要一定程度的流程变革，如果我们不推动这种流程与软件的匹配，我们最终将无法超出预期，并成为混乱数字化的兜售者。

这不是我们的宗旨，我们不会接受这一点。小型连接器必须遵循与大型连接器相同的设计和原则，以便它们能够高效扩展和增长。 大多数本地化项目要求基于当前（实际上是过去）用例的解决方案，而不是面向未来的用例，这些用例预计会有更多的文件、更快的节奏、更多的语言区域、更短的上市时间、更低的成本，以及更多的人协同工作。

如果您没有在正确的框架中出发，后续的路线修正将是昂贵且极具挑战性的，因为您将错过新实现引入的更改窗口。我们所有的连接器，无论大小，都是基于规则和参数的。

它们受相同的设计原则约束，并且都不需要 UI 才能正常运行。 UI 可以是成熟连接器的一个有趣附加组件，但主要是为了轻松更改连接器配置，而不是手动启动项目的一种方式。

如果我们与加速现有模拟流程同谋，我们就无法促进长期成功。 

相反，我们的目标是将模拟流程转化为数字思维，使它们真正兼容软件，从而实现面向数据的自动化。我们习惯于管理每天将数千个文件处理到近 100 个不同区域设置中的连接器。

多年来，我们了解到，使大规模连接器成功的相同要素也必须适用于小型连接器，以便遵守可扩展性和可持续性的基本设计原则。