复杂性的架构师：为什么你的简单任务现在需要六个冲刺

Source: Dev.to

我们都遇到过这样的人。他们不只是写代码；他们在打造“生态系统”。你只要一个简单的 CRUD 表单来记录办公室零食，结果却要参加一个关于事件驱动微服务、Kubernetes 集群以及为什么我们需要为目前只有四行数据的数据库定制 GraphQL 包装器的三小时会议。

这就是 复杂性架构师。他们不是为业务而构建，而是为自己的智慧建造一座纪念碑。

你正在与过度工程师打交道的迹象

• 他们的 PR 中包含 dozens（数十）个新抽象，针对一个尚未被请求的功能。
• 他们把“解耦”提升到一种程度，以至于你根本找不到实际逻辑所在。
• “规模化”是他们最喜欢的词，尽管该应用只有十二个用户，其中三位是 QA 团队。

为什么这会毁掉团队

复杂性是一种债务，业务每天都要为其支付利息。每一行不必要的代码都是需要测试、加固，并在“下一个大框架”出现时进行重构的代码。

真正的高级做法：激进的简化

这并不酷。你不会在 LinkedIn 上写上 “管理了一个分布式无服务器函数网格”。但你会在周五交付功能，业务赚钱，而且不会因为 sidecar 代理突发的“存在危机”在凌晨 3 点收到 PagerDuty 警报。

如何抵制复杂性蔓延

• 如果解决方案需要你从未听说过的三个新库，那很可能是错误的。
• 记住，代码是一种负债，而不是资产。最好的代码是你根本不必写的代码。
• 停止奖励让事情变得困难的人。智慧不是体现在你能处理多少复杂性，而是体现在你能消除多少复杂性。

行动号召

下次有人为博客平台建议微服务架构时，帮大家一个忙：给他们一份业务需求文档和一次现实检查。

你维护过的最荒唐的过度工程“解决方案”是什么？在评论区留下来，让我们都对自己的技术债务感觉好一点。