主页
对于全球成千上万的营销人员来说，Braze 仪表板是他们让事情发生的地方。 确保该界面处于最佳状态所涉及的工作由从产品设计师到工程师的各种不同的人承担。 虽然这些优化通常与用户界面有关，但同样常见的是，它们与支持仪表板的技术有关。
近年来，该领域最重要的转变之一是我们弃用了RequireJS并将仪表板迁移到Webpack ，这是由 Braze 高级软件工程师 Alex Guerra 带头的一项工作。 让我们来看看 Guerra 对这个项目的重要贡献，迁移过程的来龙去脉，以及随后的速度改进如何使解决与仪表板相关的编码问题变得更加容易。
说起来很有趣，但我最终几乎是偶然地参与了 RequireJS deprecation 项目。 我在 Braze Engineering 的消息传递和自动化团队工作了大约 18 个月，该团队专注于优化我们核心产品的后端消息发送管道。 在某个时候，我问过另一个团队成员前端是如何工作的——虽然他对此有一个模糊的概念，但他并不清楚具体的细节。
这让我很好奇； 我真的很想了解我们的仪表板是如何工作的。 而且因为 Braze 举办了允许员工追求激情项目的黑客日，我决定利用下一个黑客日通过绘制和记录前端代码来探索我们仪表板的细节。 大约在同一时间，Braze 仪表板团队一直在考虑从 RequireJS 切换到 Webpack，预计这将是一项重大任务。 但是在我的探索过程中，我开始看到一条前进的道路，我认为可以帮助仪表板团队自动化升级支持 Braze 平台前端的软件所涉及的一些工作。
但是要全面了解我们希望改变的内容以及为什么我对它如此兴奋，您必须了解 RequireJS 和 Webpack 之间的区别。
那么，Braze 仪表板到底是什么？ 在最基本的层面上，它是一个单页 JavaScript 应用程序。 当营销人员访问 Braze 网站并登录我们的平台时，他们收到的 Web 视图通常由仪表板代码的捆绑版本通知。 该捆绑包收集了用于生产的不同文件，并对其应用了几种不同的优化，以帮助仪表板更有效地运行，包括：
缩小以使其加载更快
自动代码修改，让仪表板适应不同的网络浏览器
代码拆分以允许前端代码按需加载
在 Braze，我们的 JavaScript 代码的资产捆绑过程最初是由 RequireJS 支持的，RequireJS 是一个专为 Web 使用而设计的 JavaScript 文件和模块加载器。 但随着时间的推移，Braze 产品和工程组织达成了共识，即我们需要改进为仪表板捆绑代码的方式。
最大的激励因素是需要加快构建过程。 开发人员每次想要验证他们对一段代码所做的更改时，通常都需要完成构建过程，以确保他们的调整以他们期望的方式影响软件。 一旦明确 Webpack（一个开源 JavaScript 模块捆绑器）可以比 RequireJS 更快、更有效地执行这些复杂的构建，我们就知道是时候做出改变了。
特别是，我们认为进行更改将具有三个主要好处：
那时，仪表板的前端基本上一分为二，一半是用 CoffeeScript 编写并使用 RequireJS 构建的，另一半是用 JavaScript 和 TypeScript 编写并使用 Webpack 构建的。 正如您所料，跨界共享代码是一个问题，并且在很多情况下，需要一些非常脆弱的黑客才能使其全部工作。 因此，迁移到单个流程所涉及的工作的一个主要好处是，它提供了一个真正统一和现代化代码库的黄金机会。
正如我上面提到的，与该项目相关的一大优先事项是寻找方法来缩短在仪表板上工作的工程师的反馈周期。 那时，如果您对前端代码进行修改，与 RequireJS 的捆绑过程平均需要 3 分钟，有时甚至可能长达 8 分钟。 这让工程师等待找出他们的代码是否正常运行需要很长时间。 使用 Webpack，初始启动时间大约为 90 秒，但每次额外的更改都可以显着加快，从而使工程师能够更好地利用他们的时间并完成更多工作。
查找和解决代码错误是任何工程团队工作的重要组成部分。 在 Braze，我们使用一种名为 Sentry 的产品，当问题出现在生产仪表板中时，它可以帮助组织和追踪问题的根源。 但是因为该代码是使用 RequireJS 构建的 CoffeeScript，所以当它被编译和缩小时，像“navigateToPill”这样的函数的描述性名称将被重命名为“a”。 反过来，这意味着我们会在第一行第 200,000 列的“a”中看到一个类型错误——正如您想象的那样，这使得确定该错误的来源需要做很多工作。 另一方面，Webpack 有一个名为 Source Maps 的工具，它允许团队获取缩小的代码并将给定的列和行映射到源文件； 这意味着您会收到 Sentry 报告说“navigateToPill”在特定行有错误，从而更容易更快地解决问题。
从 RequireJS 切换到 Webpack 的必要性很明显，但这项工作的规模意味着他们预计该过程至少需要一年时间，并且需要大量复杂性和工程带宽才能实现。 当时的想法是，我们将不得不系统地逐节检查代码库并手动迁移所有内容，这确实很繁重。
我的突破，如果你想这样称呼它，是意识到我可以编写能够通过自动化过程批量修改 Braze 仪表板代码的代码，并且如果我们需要回滚这些更改，也可以取消修改我们的代码迅速地。 在我的黑客日项目之后，我最终做了一个概念验证，只是为了证明它可以工作，然后在我的业余时间继续工作，作为一种激情项目。
也就是说，直到 Braze Dashboard 团队的高级软件工程师 Greg Beaver 参与进来，事情才真正开始。 他能够将我编写的脚本作为我概念验证的一部分，并将它们整合到我们可以与其他工程师共享的工具中。 反过来，这意味着我们可以从 RequireJS 迁移到 Webpack，而不会迫使所有处理与仪表板相关的代码的工程师在我们这样做时停下来； 相反，他们能够使用该工具自动将他们正在处理的任何代码与整体更改同步。
该工具最终变得如此之快 - 只需大约两分钟即可运行 - 并且运行良好，以至于在我们为迁移做准备时，我们实际上让工程师利用它作为与 RequireJS 相关的缓慢构建的解决方法。 他们只是将他们的分支转换为 Webpack，进行了他们需要进行的更改，然后将其转换回来，以便他们可以在旧代码中提交它。
有了这个可供我们使用的新功能，我们的迁移计划是每晚在我们的主分支上运行 Greg 的工具几周，然后让人们在该分支的 QA 环境中手动审查，看看是否有任何问题。 一旦我们确信一切看起来都不错，我们就向组织的其他成员简要介绍了计划中的更新，引导他们了解如何将代码从 RequireJS 迁移到 Webpack，并在他们得到之前提醒他们一些关键注意事项进行。
由于我们的方法，一个预计需要一年多的项目最终在短短三周内完成，这非常不可思议。 更出乎意料的是迁移的影响——尤其是现在 Webpack 上的构建过程通常只需要大约一秒钟，将每次代码检查所需的时间减少了 99% 以上。
在 Braze，我们致力于营造一个环境，让像 Guerra 这样的人可以充分利用他们独特的观点和才能。 您是否正在寻求突破界限并重新构想可能的事情？ 查看我们的职业页面，了解更多关于我们的空缺职位的信息。