策略模式结合工程化在前端代码差异化的理论和实践

策略模式是通过对对代码中的控制逻辑进行一些抽象，提取控制变量中具有同一类特征的逻辑进行封装后减少冗余控制逻辑的一种设计模式，事实上在 2B 类产品的开发中，我们经常需要针对不同的运行平台编写一些特定逻辑，这类逻辑通常具有一定的相同控制特征，即针对某个平台，或者针对某一类场景，如果使用 if/else 或者 switch/case 来控制会使代码的可维护性下降，并且在进行逻辑变更的时候很容易引发大规模的回归测试，导致测试成本上升。

为此需要减少通过代码的逻辑控制来实现产品差异化，而单纯的应用策略模式不足以改善此类问题，为此我们尝试将策略模式和前端工程化进行结合，并总结一些理论上的概念来普及这种模式。

我们将策略模式和前端工程化进行结合得到两种不同的应对策略

编译时策略

顾名思义，编译时策略即将策略模式运用到工程编译，我们通过开发 webpack 插件来实现一些编译策略，将平台特征，场景特征作为打包编译的选择策略，在实际构建中，如果针对平台A/B, 有不同的处理逻辑那么，通过编译时策略，可以构建两套不同的打包结果。

因为我们在实际工程中大量使用 module federation 模式，因此不同的 mf 入口可以作为策略的特征标识，比如针对平台A 的代码入口可以命名为 mf.platfomA.js，在随后的编译中 webpack 会检查每一次 import 的文件，如果带有 "xxx.$PLATFORM" 这样的标识则会以 mf 的 entry 文件的后缀作为匹配项，从而确保所有 platformA 的差异化文件都会被正确的打包到一起。

运行时策略

理论上编译时策略足以覆盖大部分场景，但实际应用中编译时策略往往在一些需要灵活性的场景会显得过于笨重，编译时策略要求你为某种特征新建 entry，并且需要进行编译发布等措施才能上线，在一些需要动态性的场景则无法满足，此时需要借助运行时策略进行代码的差异化控制，而这一点可以通过动态 import() 来实现，例如我们针对 N 渠道设计了 N 模块，每个渠道需要在运行时导入对应的模块，通过 import(), 将导入模块的命名利用提前注入的特征变量进行运行时的计算来获取最终要获取的文件模块名。

对于差异代码之间的共享问题，可以通过 组合(compose)/合并(merge) 来解决，这里延伸出另一个问题，至少在前端开发领域，我们通过实践获得一项感知是，对于代码的维护，简化事先措施，比加强事后措施更重要，这通常是因为目前大部分代码都是应用软件，而应用软件的变化特征和竞争特征往往缺乏垄断地位，这导致这类软件的利润并不足以保持一只非常强大的工程师团队来维持高水平的代码维护措施，例如严格的设计规范和频繁的 CodeReview，对于大部分团队来说，为此简化整个维护架构，降低事后的人工措施有助于降低整个研发团队的维护成本，关于这个问题后续再聊吧。