‘NewDev’的 Tech 偏见：当新颖性掩盖效率

Source: Dev.to

为什么在行业工作了 15 年后，我仍然选择使用纯 PHP 和 PostgreSQL 构建企业系统

六个月前，一位初级开发者问我：“你为什么不使用 React 和微服务？你的技术栈看起来像是 2010 年的”。这个问题让我会心一笑并深思。我已经有 15 年的企业系统开发经验，见证了技术的兴起与衰落。唯一不变的教训是：企业软件必须比技术潮流更持久。

新奇偏见

最近我看到很多团队仅仅因为“框架出了新版本”就重写已经稳定的系统。我知道一个案例，他们把一个 ERP 从 AngularJS 迁移到 Angular 15，花了 6 个月，却 没有 增加任何新功能。业务方为此支付了 20 万美元，只是为了拥有更 “新” 的依赖。

事实是：

• PostgreSQL 已经稳定运行了 25 年。
• PHP 已经稳定运行了 28 年。

我们真的需要去更换已经可用的东西吗？

过度架构的隐藏成本

我看到的系统结构大致如下：

API Gateway → Auth Service → Business Logic → Database

• 15 个微服务服务 100 个日活用户。
• GraphQL 只处理 3 个基础实体。

每增加一层都会带来延迟、故障点和认知复杂度。我们真的需要这么多层来实现一个客户 CRUD 吗？

简历中的趋势

上周我审阅了简历，80 % 的人提到了 React、Node.js、Docker，完全没有提到 “可维护性” 或 “长期稳定性”。我理解求职的压力，但开发不应该成为收集流行技术的竞赛。

真实案例

• 会计系统（2015）：使用 PHP + PostgreSQL 构建，至今仍由 4 支不同的团队维护。关键在于：零外部依赖，没有需要更新的 package.json，也没有会被破坏的 composer.lock。
• Vue 2 → Vue 3 迁移：迁移 3 个月后，生产环境仍然出现 bug。成本：50 万美元的开发工时 + 因不稳定导致的客户流失。
• 使用 Kubernetes 的创业公司：为 50 个并发用户实现了 service mesh 和 circuit breaker。系统复杂到只有 2 位开发者能理解——而这两位随后都离职了。

企业软件的原则

企业软件应能使用 10 年以上。这意味着：

• 使用成熟的技术，而非实验性的。
• 依赖最少（或没有）。
• 编写架构文档，而不仅仅是代码文档。
• 层级越少，故障点越少。

规则： “如果它不为业务创造价值，就不应进入系统”。

我们推荐的技术栈

• PHP 8.4 + PostgreSQL：经久不衰的组合。
• 直接使用 SQL：最高性能，最小开销。
• 每个模块使用原生 JavaScript：零 npm 依赖。

深思熟虑的决策带来的结果

一年前，我决定在一个新的税务系统中摒弃 React、TypeScript 和 GraphQL。结果如下：

• 响应时间始终保持在 < 100 ms。
• 维护成本降低了 60 %。
• 任意开发者在 2 天内即可读懂代码。

这个决定受欢迎吗？不。它有效吗？完美无缺。

引导技术选型的提问

1. 这项技术是为业务服务，还是为我的简历服务？
2. 它能维持 10 年吗？
3. 如果主要维护者离职，会怎样？

软件开发不是技术的走秀，而是为业务打下坚实的基石，即使这些基石看起来“无聊”。

结论

你是更倾向于一个能使用 10 年的系统，还是一个在 Twitter 上看起来很酷的系统？
欢迎在评论区分享你的经验和看法。

#opinion