全部文章 35 篇
按时间排列的实战拆解：架构与中间件、AI 落地、技术与业务之间。
- 响应式事务的收尾去哪了：空完成丢掉回调，有值挂死链路
给返回 Mono 的 @Transactional 方法做 afterCommit 回调时，有两个缺陷的形状很常见：Mono<Void> 空完成让注册的回调整个被跳过，而没收尾的 Sinks 让有值那条路永远不结束。两个缺陷的症状相反，所以…
- 业务系统里的 Agent 这个词，早就有主了
想把智能体接进 ERP 这类单据系统，第一个障碍不是模型：Agent 在这套代码里指经销商，一张单子算什么状态、卡在哪一步的判断住在上百个状态枚举里，要改一张单子还得穿过分布式事务和审批流。本文给出取材顺序和一份能立刻开工的状态字典做法。
- 数据改造四步：哪一步之后就退不回去了
改造里唯一真正退不回去的是数据：代码能退，写歪了的数据退不回。这篇按四步说它各自会在哪儿出事——先扩后收为什么把删旧列推迟到旧系统退役之后、双写挂在哪一层会让两边不一致时听谁的、线上还在写的时候对账怎么才算对上了，以及切读这四步里，能退回的…
- 灰度不是进度条，放的是最多赔多少
改造里的灰度常被当成进度来汇报，它真正的作用只有一个：把一次大失败换成几次小失败。这篇写切流能切多细的五档、放量为什么先看放进来的是哪类操作而不是放几个百分点、开关要有主人和到期那天、回滚要当场答出的三个问题，以及为什么演练必须换一个没参与…
- 改造这笔账：工期怎么估、什么时候停手
改造估工期的真正毛病不是估多估少，是那串数没法核对——按模块估出来的三个月，开工之后没有任何东西能校准它。这篇写怎么一个批次一个批次地算四笔钱（最常被漏的是老代码下线那笔）、新旧两套同时跑的这段日子怎么折算成本、立项那天就该写下的三个停手条…
- 上线那天，「完成」这个词最容易被用坏
上线不等于改造完成。验收要同时对五个问题拿出别人能核对的证据：改前改后行为一样吗、数据对得上吗、性能变差了吗、接手的人管得住吗、一个没参与过的工程师能改吗。这篇给出每一关要回答什么、拿什么当证据、性能基线怎么取（要看慢的那一头的数，也要看机…
- 没有测试的老系统，先让它自己交代行为
改造期最贵的不是写新代码，是没人说得清老代码现在到底在做什么。这篇讲这套新旧比对的能力为什么要单独排成第一个批次：黄金文件的输入怎么挑、输出记到哪一层才算够、时间戳和自增 id 这类干扰字段怎么先抹平，写接口得先把副作用隔开才有得比，以及比…
- 老系统改造：先证明能改，再谈怎么改
多数改造项目不是方案选错了，是开工前有三件事没人要求它回答：流量能不能切、改前改后的行为能不能比对上、数据改歪了能不能退回去。这篇给出开工前必须先过的三关、四类盘点各自要拿出一份什么东西、最容易漏的五样没写在文档上的约定，以及为什么「不改」…
- 生成不再是瓶颈，验证才是
Thoughtworks 在 2026 年上半年的工程报告里把话说明白了：代码生成不再是瓶颈，验证才是。这篇讲这个判断在数据上怎么站住，以及它在一次真实改造里具体长成什么样——验证税要交给谁、什么时候交。
