代码质量与重构
设计原则讲的是边界该画在哪里，这个专题讲的是边界之内的代码：名字是否说清了意图，重复的是不是同一条知识，一个方法拆开之后行为有没有变，参数、局部变量和控制流怎样写才让读者少记一些状态。每一篇都拿改动前后的代码一起运行，用测试或比较器证明哪些写法保住了行为、哪些没有。
从哪里开始
先读 从症状到重构手法，它把常见的代码信号和对应的手法、风险放在一张表里；再按需要读具体的一篇。每一篇都配有可运行的实验，结论以实验输出为准。
文章
01从症状到重构手法代码信号只是调查的入口：同一个信号先问背后的问题，答案不同手法可能相反；重构手法成对出现，每一步都要能证明行为没变→02名字说的是什么：动作、角色与改名的边界名字说意图不说步骤；集合、角色、布尔值的命名；IDE 改名看不到 JSON 字段、反射、存储的枚举与配置键，旧消费方读到 0→03抽一个公共方法之前：同一条知识，还是只是长得像税率写两处改一处，开票 109 退款 106；合并偶然相似的规则后优惠码接受中文；提取改变了失败语义、求值次数与短路→04把长方法拆开，哪些行为最容易被改掉2000 个随机订单逐个比较：合并循环让 271 个订单多出副作用，交换折扣顺序改了 95 个金额，重新分组校验改了 36 个报错→05参数放在哪里：请求数据、依赖与上下文请求数据放进单例字段后 alice 收到 hello bob；同类型参数写反返回 0 条，参数对象在构造时报错；线程池里没清理的 ThreadLocal→06嵌套、卫语句、switch 与多态：复杂度到底降了没有五种等价写法的认知复杂度 16 到 2，圈复杂度却是 6、7、7、5、3；策略写法的判断搬进了不计数的 lambda；按变化方向选写法→07换一种写法，改了哪些契约：局部变量、final 与不可变集合List.of 连 contains(null) 都抛异常，Stream.toList 不可改却接受 null；视图与快照；final 与 record 都是浅的；占位初值让编译器不再检查分支→08代码评审看什么先看失败路径与一致性，再看契约兼容与整体成本，最后看可读性；改动越小越能看到前几层；评论分为阻塞、建议、问题与记录→