上周看到一个热搜话题：一个人用AI做出了过去需要一个团队才能做的产品。评论区一片焦虑，有人说"技术管理者要失业了"。

我觉得这话说反了。AI越能干，越需要有人决定让它干什么、不干什么。真正该焦虑的，是那些还在用"做得好"来定义自己价值的技术管理者。

做得太好，是一种甜蜜的陷阱

我见过不少技术leader，包括我自己，刚做管理时的第一反应是——代码review我得上，架构设计我得参与，关键技术选型我得拍板。

原因很简单：这是我们最擅长的事，也是最有安全感的事。写出一段精巧的代码、解决一个棘手的bug，那种成就感是开会、写文档、做1on1给不了的。

但问题是，如果你的时间都花在review代码上，谁来做技术规划？谁来协调跨团队的需求冲突？谁来处理团队里那个能力强但态度差的人？

没人做。因为这些事"不急"。或者更准确地说，我们下意识觉得这些事没有"亲手写出一个漂亮的函数"来得有成就感。

身份认同才是真正的瓶颈

我在金融科技团队里见过一个典型场景。新业务要上线，技术方案讨论时，CTO问了一个架构层面的问题。整个会议室沉默了十秒，所有人看向那个最强的工程师。

他答得很好。但我在想：如果这个团队继续发展，他还是那个被提问的人，还是那个回答问题的人？

DRY——Don't Repeat Yourself。这四个字母可能是软件工程里被引用最多、被误解最深的原则。

每个程序员入行第一天就被告知：重复代码是邪恶的，看到重复就要提取，看到提取就要抽象，看到抽象就要泛化。于是我们疯狂地消灭重复——公共函数、工具类、基础库、共享模块......代码库越来越"干净"，重复率越来越低，CI里没有任何duplicate code的警告。

然后某一天，一个业务需求来了——需要改动某个"公共"逻辑。你打开那个被47个地方引用的utils函数，改了一行，跑了一下测试——绿了。上线，结果三个业务线同时报警。你突然发现，那三个业务线依赖的是同一个函数的三种不同行为，被那个"公共"函数强制统一了。

你消灭了重复代码，但你制造了耦合。而耦合，是比重复贵十倍的技术债。

重复代码不是问题，问题是不知道为什么重复

所有关于DRY的讨论，都默认了一个前提：重复等于坏。但这个前提本身就是幻觉。

重复代码至少有三种完全不同的面目。

第一种是意外重复——两个开发者不知道对方写了同样的功能，造了两个轮子。这种重复才是真正需要消灭的，因为它意味着信息浪费和潜在的不一致。

每个技术团队都经历过这种场景：选型评审会上，几个方案摆出来，有人做性能对比，有人秀Demo效果，有人贴GitHub Star数。讨论半天，拍板一个，然后散会。团队满怀期待地开始新项目，三个月后开始骂娘。

这事儿我见过太多次了。选型时看到的都是优点，上线后暴露的全是成本。而且这些成本绝大多数在选型评审时根本没人提——不是不想提，是没人知道该提什么。

技术选型最大的陷阱不是选错了框架，而是你以为自己只选了框架。

你看到的是Demo，你看不到的是深渊

选型评审时，我们评估什么？功能列表、性能基准、社区活跃度、文档完整度。这些都是对的，也是不够的。

它们属于"可见成本"——你能在两小时的评审会上完成对比的东西。但框架的真正成本，从来不在这张表上。

最近在和几个技术管理者交流时，发现他们都在规划或已经落地了BFF（Backend for Frontend）架构。问为什么要做BFF，得到的答案惊人地一致："解耦前后端"、"提升开发效率"、"这是最佳实践"。

但当我问："你们团队有多少后端开发？前端开发呢？"，答案通常是"后端6-8人，前端3-4人"。这让我意识到一个问题：大部分团队上BFF，可能不是因为真的需要，而是因为"别人都在用"。

我想聊聊这个话题，不是要否定BFF的价值，而是想说：很多团队高估了BFF的收益，低估了它的成本。

BFF真正解决的问题

先说清楚，BFF不是伪需求。它在特定场景下确实有价值：

场景一：多端适配。你的后端API是为Web设计的，现在要支持移动端、小程序、IoT设备。不同端的数据需求、交互逻辑差异很大，用一套API很难搞定。这时候BFF可以为每个端定制API，后端保持稳定。

场景二：聚合调用。前端一个页面需要调用5-6个后端服务，串行调用太慢，并行调用又要处理复杂的依赖关系。BFF可以在服务端聚合这些调用，减少前端的复杂度和网络开销。