留下已经托着这门生意的那套栈

贵的架构决定通常是一次没人需要的重写。已经在 WordPress 上接单的店，不会因为首页换到更新的框架就更安全。一个主要是 API 和一块板的产品，不会因为我把它硬塞进店铺同一套主题就更清楚。我选已经托住行为的那套栈，并把边界留得够清楚，让一个人仍然能看到另一边。

留在生意已经住着的地方

如果收入是 WooCommerce 结账，工作就该挨着这次结账：主题、我真正信任的插件、服务器、邮件、备份。把目录搬到单独的前端，好让技术栈看起来新，那是一个项目。它本身修不好一个优惠码，也补不回漏掉的 webhook。比起收益只是好看的迁移，我更有耐心做这周就能上的一处普通 PHP 改动。

当事情本身是一个应用，有自己的规则、自己的队列、自己的后台，而且不该被弯成页面时，Laravel 才配待在那里。带支出上限和人工确认步骤的内容流水线，就是这种应用。营销站不是。

一个产品里用一门语言，不是整段职业生涯

在一个产品里我要一种主语言，这样改 API 和改屏幕是同一次审查。在整份工作里，我不假装一切都是一种语言。PHP、TypeScript 和 Python 在这里都在生产上，是故意的。错误是因为每一层是某人的偏好，就把它们混进同一条请求路径。

数据有关系、并且要数据库去强制它们时，用 PostgreSQL。店铺已经在跑、而搬走不是任务时，就用 MySQL。Redis 用来做队列或缓存，不用来当第二个真相来源。需要把部署说清楚时，用 Docker 和一个无聊的 nginx，而不是在我想学编排器的时候。

重写必须点名它消掉的那次事故

新框架要进计划之前，我先要一句话。哪一件当前栈关不掉的事故，会因为这次搬走而消失？如果这句话讲的是口味、招聘或一场会议演讲，搬走就等。如果这句话是「结账插件表达不了这条定价规则，我已经绕着它补了两次」，那是一句真的，而我在新店面之前仍会先找一块更小的补丁。更小的补丁通常就在那里。

我想在店铺旁边再加一项服务时，用的是同一条检验。队列说得通，是因为请求必须熬过一次重试。单独的前端说得通，是因为需要同一套 API 的是两个客户端，而不是一个开发者。新数据库几乎从来不会在可靠性出问题的同一个季度里说得通。您已经有的数据就是系统。搬走它是自己的项目，有自己的清单，而且修不好那个优惠码。

我能同时守住一家店和旁边的服务，因为它们在写明的边上相接：一个 webhook、一个队列、一张表。我守不住边缘是「去问做那一部分的人」的系统。那个人必须是我，上线之后也是。所以新工具得付租金。如果它没有去掉一次交接或一类事故，那是口味，口味可以等。

选那套能把下一次事故留在一个脑子里的栈。新东西得赢过这一点，而不是反过来。