研发效能 6 篇
按时间排列的实战拆解：架构与中间件、AI 落地、技术与业务之间。
- 灰度不是进度条，放的是最多赔多少
改造里的灰度常被当成进度来汇报，它真正的作用只有一个：把一次大失败换成几次小失败。这篇写切流能切多细的五档、放量为什么先看放进来的是哪类操作而不是放几个百分点、开关要有主人和到期那天、回滚要当场答出的三个问题，以及为什么演练必须换一个没参与…
- 改造这笔账：工期怎么估、什么时候停手
改造估工期的真正毛病不是估多估少，是那串数没法核对——按模块估出来的三个月，开工之后没有任何东西能校准它。这篇写怎么一个批次一个批次地算四笔钱（最常被漏的是老代码下线那笔）、新旧两套同时跑的这段日子怎么折算成本、立项那天就该写下的三个停手条…
- 上线那天，「完成」这个词最容易被用坏
上线不等于改造完成。验收要同时对五个问题拿出别人能核对的证据：改前改后行为一样吗、数据对得上吗、性能变差了吗、接手的人管得住吗、一个没参与过的工程师能改吗。这篇给出每一关要回答什么、拿什么当证据、性能基线怎么取（要看慢的那一头的数，也要看机…
- 没有测试的老系统，先让它自己交代行为
改造期最贵的不是写新代码，是没人说得清老代码现在到底在做什么。这篇讲这套新旧比对的能力为什么要单独排成第一个批次：黄金文件的输入怎么挑、输出记到哪一层才算够、时间戳和自增 id 这类干扰字段怎么先抹平，写接口得先把副作用隔开才有得比，以及比…
- 老系统改造：先证明能改，再谈怎么改
多数改造项目不是方案选错了，是开工前有三件事没人要求它回答：流量能不能切、改前改后的行为能不能比对上、数据改歪了能不能退回去。这篇给出开工前必须先过的三关、四类盘点各自要拿出一份什么东西、最容易漏的五样没写在文档上的约定，以及为什么「不改」…
