技术中立性失守：架构师呼吁重建客观评价体系

文章配图，仅供参考

　　当时后端老张蹲在工位上改代码，键盘敲得噼里啪啦，我凑过去问：“这库谁选的？”他头也不抬：“设计那边定的，说他们调研过，比开源的稳定。”我盯着屏幕上的报错，突然就想起上个月需求评审会，设计小妹举着PPT说“我们要用最新的技术栈，这样用户才会觉得我们酷”——她当时穿的那件卫衣，背后印着“技术无罪”，现在想想，这四个字比代码里的空指针还扎眼。

　　外卖到了，我拆开包装的时候，群里又蹦出来一条消息：产品经理说“用户反馈说新页面加载慢，你们架构组得背锅”。我叼着筷子翻聊天记录，发现设计那边上周刚改了交互方案，把原本的懒加载改成了全量渲染，理由是“这样更流畅”。我原以为他们至少会测下性能，结果问起来，设计小妹说：“我们用本地环境跑过，挺快的呀。”本地环境？她本地是i9+64G内存，用户手机呢？

　　后来事故复盘的时候，我翻出之前的架构文档，发现里面明确写了“核心链路依赖库需保持版本稳定，非必要不升级”，结果呢？设计那边说“用户需要新鲜感”，产品那边说“竞品都上了，我们不跟就是落后”，后端老张更绝，直接甩锅给CI/CD：“构建脚本里没锁版本，谁都能改。”我盯着屏幕上的版本号，突然就明白为什么大家总说“技术中立性失守”了——当技术选型变成KPI的博弈场，当架构决策被非技术因素绑架，所谓的“中立”早就成了笑话。

　　上周跟另一个团队的架构师吃饭，他吐槽说他们最近在选数据库，设计那边非要上图数据库，理由是“数据关系更直观”，产品那边则坚持用时序数据库，因为“监控数据需要实时展示”。他夹着烟说：“我原以为架构师是技术决策者，结果现在成了背锅侠——选A吧，设计说你不懂用户体验；选B吧，产品说你不考虑业务价值；最后选个折中的C，线上出问题，所有人都说‘你架构没设计好’。”窗外在下雨，他的话混着雨声，听得我直摇头。

　　我后来想，这事儿最荒诞的地方在哪儿？不是技术被业务绑架，而是大家明明知道技术该中立，却都在默认这种绑架的存在。设计觉得“技术应该服务业务”，产品觉得“技术应该支撑增长”，后端觉得“技术应该稳定”，可谁都没想过——技术本身的价值，不该被这些标签定义。就像老张说的：“我们架构师，本来该是守门人，结果现在成了擦屁股的。”

　　前几天群里有人发了张表情包，是只猫举着“技术无罪”的牌子，下面配文“但架构师有罪”。我盯着看了半天，突然就笑了——这不就是现状吗？当技术中立性失守，当评价体系被非技术因素主导，架构师能做的，大概只有两件事：要么跟着卷，要么重建规则。我选后者，虽然难，但至少能睡个安稳觉。

　　现在我们的新架构文档里，多了条硬性规定：所有技术选型必须通过“三问测试”——第一问“是否解决核心问题”，第二问“是否有可量化的收益”，第三问“是否可维护”。产品那边抗议过，说“这样会限制创新”，设计那边也嘀咕，说“不够酷”。我直接把文档甩群里：“要么按这个来，要么下次事故你们自己背锅。”旁边工位的风扇声嗡嗡的，我盯着屏幕，突然就觉得，或许这就是重建客观评价体系的第一步——把技术的归技术，把业务的归业务，哪怕这过程会得罪人。

　　当然，我也知道这不可能完美——毕竟“客观”本身就是个主观的词。但至少，当下次设计再提“用户需要新鲜感”的时候，我能指着文档说：“先证明它比稳定更重要。”当产品再说“竞品都上了”的时候，我能问：“他们的白屏率多少？”当后端再说“构建脚本没锁版本”的时候，我能说：“下次我会把版本号写进架构文档，谁改谁负责。”

　　至于能不能成？管他呢，至少我试过了——总比坐在工位上等外卖的时候，看着群里又炸一次强。

（编辑：我爱资讯网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!