Trivago 从 PHP+Melody 迁移到 Next.js+TypeScript

Trivago 的平台是使用 PHP 和他们自主研发的 Melody 框架构建的。Melodys 是由 Trivago 的一小部分工程师负责维护的，这存在连续性风险。由于人手不够，Melody 的文档和示例不可能像期望的那样丰富，这使得其他工程师更难参与并提供支持。后来，Trivago 决定使用 Next.js 在 TypeScript 上重写平台。

为了降低开发像 Melody 这样的自有框架所带来的风险，Trivago 工程部门必须在给 Melody 分配更多资源和放弃它之间做出选择。最终，他们决定停止使用 Melody。

对企业来说，这样的平台替换可能会有影响收入，因为在重写期间无法引入新功能。2020 年，项目在此类风险降低的情况下开始。

另一项风险是，在现有功能移植完成之后，新功能仍被搁置的话，开发团队的积极性就会丧失。因此，一旦新平台足够稳定，团队就需要开始构建新的功能，避免降低团队积极性。

开发体验、黑客马拉松成果和市场渗透率是选择新技术栈的决定性因素，团队最终决定采用：Next.js和使用 TypeScript 的Preact。采用应用广泛、有大量社区支持的库，开发人员将受益于更整洁的代码库。

在使用新技术设计新平台时，必须做许多架构决策。必须及时、务实地达成协议，以确保项目成功。Trivago 的工程师们使用了一种架构决策记录的形式。按照Tom Bartel的描述，这个过程基于以下几点：

决策文件将所有相关的事实和观点收集和组织起来。

 

决策负责人负责策划决策文件，准备决策会议，并负责达成决策。

 

决策会议上交流和讨论观点，并在最后做出决定。

从这个项目中得出的最重要的一条经验是，团队不应该发展得太快。作者指出，当少数几名工程师一起工作时，试验和处理方法都很容易更改；只有当所有关键决策都做完了，基础稳固了，才能将团队的规模扩大到 5 人以上。这样做可以防止沟通开销、挫败感和精力浪费。

既然是重写，新系统就需要实现与现有平台相同的功能。团队通过以 A/B 方式运行两个平台并比较一些指标，如用户互动、创收和搜索类型，以验证正确性。

作者补充说，重写还给终端用户带来了好处，新平台加快了应用程序的加载时间。

作者简介

Vasco Veloso 从事软件开发和设计已经有二十多年了。从汇编到 C、C++和 Prolog，再到 Java、Scala 和 Kotlin，在大型和小型机上，从软盘到 SSD，在企业内部和云端，他都经历过，做过，也用过。他把团队团结在一起，开发出精心设计的软件。他还喜欢通过教学来分享知识，并继续设计软件和联网设备。在业余时间，他会探索阿姆斯特丹这座城市。他喜欢摄影，并对航空业非常感兴趣。他曾驾驶过超轻型飞机。他相信，只要保持必要的关注，他就可以继续飞行、到达目的地并享受沿途的风景。

原文链接

Trivago’s Journey From PHP+Melody to Next.js and Typescript