前端开发者在非开发任务上耗时过多。Jouke Visser倡导前端平台工程，通过集中管理、整体方法和开发者认同，解决痛点，提升效率，减少技术债务。
译自：Why the Frontend Should Embrace Platform Engineering
作者：Loraine Lawson
一份2025年Atlassian报告发现，50%的受访开发者每周在非开发性质的杂务上浪费超过10小时。但Jouke Visser表示，在前端领域，情况可能更糟——因为生态系统发展得太快了。
Visser认为，平台工程可以提供帮助。他是一名前端平台工程大使。他还是FrontenderZ的创始人兼首席架构师，这是一家专门帮助大型企业设计、构建和扩展内部前端开发平台的咨询公司。我们询问Visser为什么前端在平台工程工作中被忽视。
“去年六月，我在伦敦参加平台工程大会时，我走向Kaspar von Grünberg [平台工程的早期先驱]并问了他同样的问题，”Visser告诉The New Stack。“他说，‘看来谈论这个话题的人不多——你为什么不加入我们的大使计划呢？’”
面向前端的平台工程
Visser说，前端在平台工程中被忽视太久了。他自2017年以来一直在该领域工作，当时他获得了前端平台解决方案架构师的头衔。
“我开始研究——嗯，那时间很短，因为市面上根本没有相关的东西，”他说。“我真的不得不自己重新发明轮子。”
其他组织也在进行类似的倡议，但并不一定称之为平台工程。他说，他们更多地将其视为开发者体验或开发者赋能问题。与后端平台工程相比，他们的努力显得杂乱无章。
他补充说，这导致前端在依赖项上经常落后。
“通常是我们落后了React两个版本，或者我们有一个不兼容的更新要推出，或者我们改变了架构，却不知道如何联系到那些几乎从不处理任何前端事务的团队，并让他们保持一致，”他说。“这个领域的杂务太多了，至少与后端开发相比是这样。”
他补充说，后端非常依赖API契约，而对于前端，唯一可以确定的是用户不会全部集中在一个浏览器窗口中。
“你如何管理所有这些复杂性？”他说。“希望一切都兼容，运行良好，而且看起来也不错，对吧？”
创建前端平台
当时，Visser正在一家公司工作，该公司有一个大型的monorepo，涉及160个团队只处理几个应用程序，由一个平台团队负责所有依赖项的生命周期管理。
基本上，团队建立了一个为期六周的发布周期，期间他们会进行各种更新，包括破坏性变更。然后他们关闭PR一小时，并合并分支。那时，每个人都必须进行rebase。
如果测试证明某些东西不起作用，并且升级过于复杂，他们就会将其撤回，以便进行构建，并在下一个六周周期中处理修复。
“所有这些事情都是相互关联的，我认为如果你退后一步，对开发者需要使用的整个生态系统采取整体方法，那真的会有所帮助，并且也能建立良好的开发者体验。”
—— Jouke Visser，前端平台工程大使
“不是让所有160个团队中的每个人都各自处理自己的更新，而是一个团队平均花费总时间的三分之一，来编写这些类型的变更脚本，”他说。“这只是照顾了160个团队，让他们再也不必担心任何升级。”
不可避免地，有些团队落后了，直到发布前才进行测试，但平台工程团队采取了立场：这是既定的节奏，不会等待一两个尚未准备好的团队。
“那种严格性带来了合规性，”他说。
这种纪律是在他第一次成为平台工程师时发生的情况中诞生的。
“我们在AngularJS上严重落后，根本无法组织一次性升级，除非我们花费六个月的时间来协调不同团队，”他说。“银行对我们落后如此之多感到不满，这成了一个首要任务：始终保持所有第三方依赖项的最新状态，并对任何依赖项报告的所有安全问题进行全面合规性检查。”
这导致了一个洞察：依赖项需要进行大规模的组织。
“你如何做到这一点？通过集中管理责任，但仍需与产品团队合作，”Visser说。
他承认这是一个缓慢的过程，需要几年时间才能真正融入组织。但他补充说，现在这家公司已经领先于其他组织。
开始前端平台工程
他说，任何平台工程工作的第一步是获得开发者的认同，确保平台通过为他们解决问题来为他们的工作带来价值。
“面对现实吧，我们是工程师；最固执的人就是我们，我认为我也是其中一员，”Visser说。“如果你知道如何解决问题，如果你习惯了某个工具，你不一定会因为别人让你改变就愿意改变。”
为了获得认同，进而促使平台被采用，他建议首先采访并调查平台将服务的开发者。询问他们对平台的需求和期望。
“这关乎他们面临的问题以及他们希望如何在开发流程中工作。如果你能做到这一点，那么对话就不再是关于你实际使用的技术了。”
—— Jouke Visser
“如果我构建一个平台并标准化使用Yarn，而世界其他地方都在使用PNPM，我告诉他们‘因为我说了算，你必须从PNPM改用Yarn’，他们会说‘我们倒退了’——这不是你在实施平台时希望进行的对话，”他说。“这是你需要提前进行的讨论，[同时]确保你正在构建正确的东西。”
他补充说，平台工程不仅仅是关于工具或技术。
“这关乎他们面临的问题以及他们希望如何在开发流程中工作，”他说。“如果你能做到这一点，那么对话就不再是关于你实际使用的技术了。”
其次，一个开发商店理想情况下应该识别是什么原因导致开发者花费最多时间。这将为平台工程师找出痛点。
“以产品化的方式，以可重复和自动化的方式很好地解决它，那么我们就能真正帮助组织解决那个特定的痛点，”他说。“这建立了信任，[相信]如果他们能以这种方式处理我们正在努力的其他方面，那么我们就能循序渐进地构建一个平台。”
前端平台工程需要整体方法
他补充说，平台工程也应该采取整体方法。
“这不仅仅是关于依赖项，因为如果你谈论依赖项，那么它会自动反映出你自己构建了什么以及如何构建，”他说。“为了能够灵活地在不同框架之间切换，例如，或者支持多个框架（如果那是你的目标），在核心库中以框架无关的方式实现一些核心功能，以便你可以在多个框架中重用。”
他补充说，这样做将对你构建软件的方式产生影响。
“所有这些事情都是相互关联的，我认为如果你退后一步，对开发者需要使用的整个生态系统采取整体方法，那真的会有所帮助，并且也能建立良好的开发者体验，”Visser说。
尽管Visser对技术债问题有一些不同的看法——他不确定这是否是你需要与之对抗的东西，而更应该是在开发者如何处理自己的代码时需要考虑的东西——但他表示，如果平台团队实施了正确的护栏，平台工程可以帮助解决技术债问题。
“那是我从失败中学到的最大教训，我想说，因为我们没有适当的架构护栏。我们几乎没有任何linting规则，”他说。“当在六个月内，至少有50个团队加入该平台时，他们都有自己特定的做事方式，而在标准化方面，我们没有为此做好准备。”
这教会他，平台工程师至少应该有一套基本的风格指南和架构规则——只是一套基本规则——每个开发者都必须遵守。
“这使得后期的维护变得容易得多，”他补充道。
理想情况下，前端平台工程将提供开发者所需的一套构建块——例如设计系统或客户认证。
“如果你将所有这些标准化，构建东西就会容易得多，”他说。
