政策驱动下产创融合后端架构破局烟囱式开发

　　去年十二月份那波政策下来，老张拍着桌子喊“产创融合要落地”，结果后端那帮人熬了三个大夜，最后卡在冒烟测试上——你猜怎么着？又是烟囱式架构的锅。我原以为政策驱动下大家会收敛点，结果还是老样子，各团队自己搭自己的服务，数据不通、接口不认，连灰度环境都配不齐，最后提单的时候优先级全标“紧急”，可谁都知道这是历史遗留问题。

　　那天晚上十点，测试机充电线不够长，我蹲在工位底下插插头，听见老王跟后端吵：“你们这服务A的字段类型跟服务B差了八百里，政策要求的数据互通呢？”后端小哥挠头：“当时急着赶需求，没想那么多……”我差点笑出声——这台词我听过八百遍，每次都是“急着赶需求”，结果政策一变，全成技术债。用例管理工具还在转圈，我盯着屏幕上那个“加载中”的图标，突然想起上周漏测的那个兼容性问题：用户用旧版APP上传文件，后端服务C直接报500，可测试环境根本没覆盖旧版——因为“没人用旧版了”，结果线上炸了，用户截图发群里，运营小姐姐哭着来找我。

　　烟囱式开发最坑的地方，是它让“优胜劣汰”成了伪命题。政策说要“融合”，可各团队为了KPI，宁可重复造轮子也不肯拆墙。比如那个用户画像服务，市场部要A字段，风控部要B字段，产品部要C字段，结果后端做了三个独立服务，每个都只满足一部分需求，数据还得靠人工同步。我提过好几次合并，可每次都被拍回来：“改架构要排期，这个月上线目标完不成谁负责？”所以现在的情况是：新政策来了，旧架构扛不住，可谁都不想动——因为动了就得重构，重构就得耽误进度，耽误进度就得扣绩效。

　　键盘上有个键按下去不回弹，我敲代码时总漏字母，气得把键盘摔在桌上。老张路过，瞥了一眼：“又坏了？上个月刚换的那个呢？”我指了指角落里的纸箱：“在那儿躺着呢，IT说没库存，得等采购。”他冷笑：“连键盘都搞不定，还谈什么架构优化？”我张了张嘴，没接话——他说的没错，可键盘是小事，架构是大事，大事卡在“谁都不想背锅”上，才是真的无解。比如上次那个支付接口兼容问题，政策要求支持第三方支付，可后端说“现有架构改不了”，产品说“用户需求不强烈”，最后拖了两个月，直到竞品上线了同款功能，市场部才拍桌子要求“立刻改”——结果改的时候发现，旧接口的代码里藏着三个隐藏bug，其中一个还是三年前写的，注释都没留。

　　会议室又被占了，我端着凉透的外卖站在走廊，听里面在讨论“产创融合的考核指标”。有人说“要看接口调用量”，有人说“要看数据同步频率”，我低头扒拉两口饭，突然想起测试环境那个边界问题：用户上传超过10M的文件，后端服务D会直接崩溃，可测试用例里只写了“上传5M文件成功”——因为“用户不会传这么大的文件”。结果线上出了问题，用户上传了15M的合同，后端报错，客服收到投诉，开发连夜修，修完发现是磁盘空间不足——而磁盘空间不足的原因，是另一个团队的服务把日志写满了，没人清理。

文章配图，仅供参考

　　白板上的数字擦了一半，露出底下那行“Q4目标：完成产创融合架构升级”。我盯着那行字看了五秒，转身回工位——目标还在，可架构没变，政策没变，人也没变。上周线上又出了个偶现bug，用户点击某个按钮有时没反应，复现概率1%，开发说“可能是网络问题”，产品说“用户不会在意”，测试说“用例没覆盖”——可我知道，这1%的背后，是烟囱式架构里某个服务没处理好超时，是某个接口没做重试，是某个日志没打全。但没人愿意深挖，因为深挖就要改代码，改代码就要排期，排期就要耽误进度，耽误进度就要扣绩效——所以最后的选择是：忽略它，等它变成10%的时候，再说。

　　现在我只能寄希望于“优胜劣汰”真的能发生——比如政策再严一点，把那些不改架构的团队淘汰掉；或者用户再挑剔一点，把那些体验差的系统用脚投票投没；或者老板再狠一点，把那些“历史原因”当借口的人开掉。可这些“如果”都没发生之前，我能做的只有两件事：一是把用例写全，哪怕测试机充电线不够长；二是把键盘修好，哪怕IT说“没库存”。至于架构？等政策细则出来再说吧——或者等竞品把我们打趴下，那时候，不用政策驱动，大家也会主动改。

（编辑：站长网）

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