放弃的礼物

重写

救赎恩典

是的，但我们仍然必须这样做。

放弃的礼物

由 Mux 主办的 DEV 全球展示挑战赛：展示你的项目！

我是Google Santa Tracker （网页版）的工程负责人，这是一个面向所有人的节日主题体验项目。团队主要由 20% 的志愿者组成（这是 Google 内部用来描述“内部志愿服务”的概念），不过也有几位核心工程师会在 12 月 25 日之前的几个月里参与网站的维护工作。

参与圣诞老人追踪器项目绝对是一种享受。我们的截止日期相当紧迫——精灵们会提供圣诞老人的飞行计划，该计划总是在12月24日UTC时间10:00开始。但我们也会在12月初推出圣诞老人村，那里充满了寓教于乐的体验，例如基于Blockly的编程 游戏和雪球大战。

2018 年的圣诞老人网站本质上是一个基于 Polymer 2.0 的网站，其中包含一些长达十年的代码。它极致地运用了App Shell模型——我们提供了大约 50 个独特的场景和游戏供用户浏览。部分场景会在十二月的不同日期开放，例如“追踪器”本身，它只会在圣诞老人飞行期间开放。

在技​​术栈方面，Polymer 让我们能够构建网站的“核心组件”——菜单、侧边栏、按钮和导航体验（我去年做过一个相关的视频📹 ）。它使用 Web Components，这意味着我们还需要导入 Shadow DOM 和自定义元素 polyfill 来兼容旧版浏览器。至于那些常青浏览器，那指的就是 Edge，而且在 2019 年这应该不会是个问题。这篇文章并非布道之作，但 Web Components 的确能帮助我们以符合标准的方式快速构建互联组件。

重写

因此，Polymer 2.0 使用 HTML Imports 来引入其依赖项——这是 Chrome 力推但从未被广泛采用的功能。Chrome大约在 2019 年 3 月移除了这项功能，JavaScript 控制台会及时通知您。

重要的是，我们怀疑圣诞老人追踪器在三月份将停止对Chrome用户正常工作。⚠️😱

解决方案是使用 ES 模块。Polymer 本身基本不受影响，但我们需要迁移到其 3.0 版本，这实际上是将 2.0 版本机械地转换为使用 ES 模块。

我们每年大约在 10 月份开始开发 Santa Tracker，持续两个月到 12 月份，然后在整个 12 月份发布较小的更新（有时是错误修复，有时是新游戏或视频）。

今年，我们首先启动了 ES 模块的迁移，并着手对 Santa Tracker 进行现代化改造：也就是重写整个程序。虽然工程师们都乐于重写程序，但我们觉得基于 Polymer 的版本（最初设计于 2013 年左右）已经过时：构建耗时超过 20 分钟，而且使用的工具也早已被淘汰。因此，重新构建一个全新的代码库是明智之举。

这个过程持续了几周。我上面提到的“应用程序外壳”大部分已经移植完成。我们没有选择 Polymer 3.0，而是选择了lit-element。但是，迁移我们 50 个独立的场景（其中一些场景的代码已有十年历史）的进度相当缓慢。面临的挑战包括：

• 为了提升性能和安全性，我们将每个场景都移到了单独的框架中<iframe>，而不是将代码放到父框架里。

• 有些现代场景是专门使用 Polymer 2.0 编写的，而不是使用可移植的 JavaScript。

• 与先前构建系统的紧密耦合

这让人很焦虑。进度比我们预想的慢——因为我们只有50个工作单元，所以很容易就能看出项目进度和12月1日的对比情况。我们不得不向用户发布一个精简版的圣诞老人追踪器。

于是，在被重写工作压得喘不过气来几周之后……

我们停了下来。

12月1日前一周多一点，我们最终决定不值得这么做。我们当时专注于开发者体验——新的代码库简直太棒了：编译时间缩短了十分之一，正确使用了ES模块等等——但如果发布新版本，将会损害用户的利益，他们只会觉得缺少一些游戏或功能。

救赎恩典

细心的用户可能已经注意到，我们保留了部分新代码库。今年推出的一款新游戏《精灵制造者》（Elf Maker）🧝‍♀️就是通过旧代码库加载新<iframe>代码库的——你可以从它的使用方式以及游戏内部如何使用lit-element看出这一点。

尽管感觉有点脆弱——为了构建和发布 Santa Tracker，我们现在有两个完全独立的存储库，通过巧妙地结合gulp手写构建脚本和 bash 来实现——但这确实比任何人预期的都要好。

虽然团队认为完全重写是最合理的选择，但我们一开始有点工程上的自负：这当然是正确的决定，代码库已经过时了等等。通过“放弃”完全重写，但仍然发布了一些新的东西，我们学到了很多东西，而且在此过程中没有对用户体验产生负面影响。

迁移到 ES 模块的工作必须在 2019 年 3 月之前完成。但现在，我们掌握了更多的数据，可以做出明智的决策来实现这一目标。

是的，但我们仍然必须这样做。

我们推迟了一个问题。圣诞老人追踪网站需要在2019年3月之前完成迁移，但我们现在的情况要好得多。

虽然“圣诞老人追踪器”是一个节日主题网站，而且我们的大部分用户都在十二月访问，但我们全年都提供服务。这一点尤其适用于我们的教育游戏，我们知道教育工作者全年都会使用这些游戏。在我居住的悉尼，情况可能更是如此，因为这里的寒冷主题在一年中的其他时间才更贴切，而且12月25日的气温高达30摄氏度以上。

这意味着我们希望在10月份圣诞老人追踪器正常开发周期开始之前完成这项工作。但是，通过做出艰难的决定，暂时不发布新的代码库，不让自己疲于奔命地移植场景，最终却又回到原点（至少从用户的角度来看是这样），我们可以更好地完成这项工作，而无需承受巨大的压力。

我承认自己身处特权地位：大多数工程师没有机会参与节日主题网站的开发，而是受制于客户、商业需求和时间节点。但在很多方面，“圣诞老人追踪器”也具有类似的特点——谷歌每年都做这个网站，因为它有趣，也因为人们喜欢，但我们同样面临着严格的截止日期——圣诞老人和节日季实际上就是我们的客户。

放弃的礼物

圣诞老人追踪团队现在要好好休息一下了：就像圣诞老人和他的团队一样。

是的，我们得在2019年初就投入工作，为几乎整整一年后的假期做准备。但我们可以妥善完成，而且不会影响用户体验。在我看来，这才是真正意义上的技术债务。

我希望你能在这个假期给自己一份“放弃”的礼物，以减轻压力，同时让你的用户同样满意。

感谢今年所有帮助过圣诞老人追踪器项目的人们。