3200 行的 OrderService，AI 说拆成六个类 四月初我接手了一个历史模块的重构。OrderServiceImpl 单个文件 3218 行，包含下单、支付回调、退款、履约、对账、通知六种职责，方法之间互相调用，改一个地方要心惊胆战地检查半小时。这活儿我拖了两周没敢动。 后来试着把整个文
三个人都点了 Approve，上线还是出了事故 9 月底的一次线上故障，起因是个不到 200 行的 PR：修改优惠券核销逻辑。三个人 review 过，两个 LGTM 加一个 Approved，上线两小时后，监控发现优惠券超发了 1.7 万张。 复盘时我把三个人的评论翻出来看，发现一个规律： 评审人
复盘：一次被迫停更的迭代 四月那次版本上线前夜，我盯着依赖图发呆——一个订单核心模块被 27 个地方引用，改一处要回归 40 个用例，测试同学直接摆烂说「这版先别动它」。这不是第一个被技术债拖住的需求。入行第六年，我越来越觉得，技术债不是写烂代码，是「明知该改但一直没改」的累积。 债务识别：先把账算
几个年头里反复踩的坑 建表时随手选类型，上线后不是慢就是错。我整理了团队里最高频的几类字段选型问题，新项目开工前照着过一遍。这些坑每一个都对应过一次线上事故或一次漫长的数据迁移，所以值得写下来反复提醒。 varchar 长度 有人图省事一律 varchar(255)，其实 MySQL 在 utf8m
那个 3000 行的 Service 接手交易核心模块时，OrderService.java 有 3128 行，下了 47 个 @Autowired 的 DAO 和远程 client。任何一处改动我都得屏住呼吸。上周一个改下单幂等的小需求，回归测试就跑了三轮，改动 8 行、提心吊胆一整天。更糟的是，
编译一次 8 分钟，改一行代码等半天 5 月中旬，我们的主工程已经长成一个 47 个 package、21 万行的单体。mvn clean install 的时间： $ time mvn clean install -DskipTests [INFO] BUILD SUCCESS [INFO] To
半年内第四次，又是新 SQL 没索引 2021 年 5 月 10 号，一个上线不到两小时的功能把数据库打挂了。原因是一段新写的查询没走索引，全表扫 4000 万行。 难受的是，这不是第一次。我翻了下过去半年的故障记录： 日期 原因 影响时长 2020-12-08 新接口 SQL 未加索引 47 分钟
我写的 180 行 if-else 被 review 打回了 上周做了个订单状态流转的需求，我吭哧吭哧写完，自我感觉良好地提了 MR。师傅留了一条评论："状态机别这么写，用枚举。" 先看看我交上去的东西： @Service public class OrderStateService {
接手了一个 4000 行的 Service 类 三月底，组里那个做了两年的老项目交到我手上。第一次打开 OrderServiceImpl.java，IDEA 右下角显示 4127 lines，我愣了一会儿。往下翻，一个方法从 1032 行开始，到 1450 行结束，中间嵌套了 7 层 if。 更绝望
