2025 年 6 月 19 日，我参加了圣彼得堡的 PiterJS #79。那晚的主题并不炫目，反而因此很实用：不是讨论怎么交付下一个新功能，而是讨论怎么维护已经做出来的东西——monitoring、deployment 和 refactoring。
议程和这个主题非常一致。Pavel Shlykov 讲的是如何改善一个老旧 monolith，Alexander Panfilov 讲 FrontOps，Igor Antonov 则讲 Web 应用性能指标。这三个方向我都记下了不少能继续思考的内容。
意外的是 Q&A。我最后因为在问答环节提出了最好的问题，拿到了两个奖品。这当然不是什么重大的技术成就，但它反而成了那晚最让我记住的细节，因为它再次说明了我为什么仍然重视线下技术 meetup：你不只是消费一场准备好的演讲。趁讲者还在现场，你可以直接检验自己到底有没有理解对。
真正有用的主题是维护，而不是新鲜感
Frontend 活动很容易变成新 framework、新 API 和新 abstraction 的展示会。PiterJS #79 更接地气。它公开的主题就是如何支持已经存在的软件。
这很重要，因为大量工程工作是在第一次成功发布之后才真正开始的。Legacy monolith 并不自动等于坏系统，“现代化”也不自动等于全部重写。更实际的问题通常要窄得多：现在真正限制系统的是什么？什么改动能减轻这个问题，同时又不会引入比它消除掉的风险更大的新风险？
这也是为什么三场分享放在一起很顺。Refactoring 改变代码。FrontOps 改变 frontend 如何 build、打包、交付和运行。性能工作改变我们如何测量结果。它们属于不同层，但解决的是同一类问题：系统长大之后，怎么继续让它保持可理解、可控制。
FrontOps 不只是一个 Dockerfile
我在 meetup 上记下的一点，是使用 Docker 实现 FrontOps。这里最重要的区分是：Docker 是工具，不是 FrontOps 的定义。
Frontend 的责任并不一定在 npm run build 成功时结束。到了 production，仍然要有人考虑可复现的 build、artifact 如何打包、配置如何进入应用、release 如何 rollback、cache 怎么工作，以及故障如何被观察到。Container 可以让其中一些流程更可预测，但它不能代替这些运维决策本身。
这也纠正了一个很常见的思维模型：build 成功，只能证明 build 完成了。它不能证明应用一定会被正确部署，也不能证明它在 production 中一定行为正确，更不能证明出问题时一定容易恢复。
性能优化首先要定义什么叫“慢”
性能分享最实用的地方之一，是它对“测量”这件事的 framing。公开的议题范围包括影响加载速度的因素、不同的 frontend 性能指标、如何把“慢”量化，甚至还包括为什么并不是所有情况都需要优化。
最后这一点很容易被低估。“让它更快”听起来像一个客观目标，但如果没有指标，也没有用户真正能感知的问题，它很容易变成昂贵的猜测。一个有用的性能流程应该从定义到底哪里慢开始，然后测量、定位瓶颈、改一个真正相关的因素，再重新测量。
一个 metric 本身不等于 user experience，但它至少让讨论有一个共同单位。没有测量，性能工作很容易变成一堆技术上很漂亮的改动，却没有清晰证据说明真正重要的问题是否改善了。
Q&A 改变了这次 meetup 对我的价值
我完全可以之后再看录像、收集链接。更难复制的是分享周围发生的互动。要提出一个好问题，你必须把自己的不确定性压缩成足够具体的东西，让另一个工程师可以真正回答。
拿到两个奖品当然很开心，但更有价值的结论更简单：带着参与的准备去线下 meetup，比把它当成一份直播 YouTube playlist 来看，能得到更多东西。
一个好的技术问题通常需要 context 和 constraint。与其问“最好的架构是什么？”，更值得问的是：如果团队不能重写 legacy system，trade-off 会怎么变化？如果 deployment 必须保持 backward-compatible，怎么选择？如果某个性能 metric 变好了，但用户没有对应的可感知收益，又该怎么判断？
这并不意味着每个问题都必须显得聪明。重点是它能不能帮助暴露假设、边界或 failure mode。
下一次技术 meetup，我会带着这些原则去
- 先知道一场分享为什么和自己有关。 开始之前写下一个真实问题或一个不确定点。
- 把讲者的经验和自己的系统分开。 一个好的 case study 是证据，不是通用配方。
- 问 trade-off。 “什么时候你不会用这个方案？”往往比“哪个工具最好？”更有信息量。
- 留下一个后续动作。 一条笔记如果能指向 meetup 之后需要验证、测试或继续阅读的内容，就更有价值。
- 不要把有说服力的分享当成 production proof。 架构、deployment 和性能决策仍然需要在自己的环境里验证。
最后真正留下来的东西
我不想夸大一次 meetup 能改变多少东西。我没有从 PiterJS 带走一个通用的架构答案，一场好的分享也不能替代 documentation、profiling、testing 或 production data。
我真正带走的东西更具体：关于现代化 legacy monolith、使用 Docker 做 FrontOps、Web 性能测量的实用笔记；Q&A 的两个奖品；以及又一次确认——本地开发者社区值得亲自去参与。
录像可以保存演讲。最难保存下来的，是演讲周围发生的那场对话。