评审总被要求拆方法 两百行到底按什么边界拆

// 按步骤命名
extract() -> reserve() -> pay() -> notify();
OrderContext ctx = new OrderContext(order);

评审时被要求拆方法，一个两百行的下单流程拆成八个只有两三行的小方法，参数在方法之间来回传，读起来反而更绕。先别急着动参数，把报错原文和时间点记下来，顺序反了容易白折腾。

原因不复杂，拆的边界按行数切，没有按职责和变化频率划分，共享的中间结果靠参数层层传递，调用链拉长了但耦合一点没降，评审下一轮又提同样的意见。

「方法过长拆分」排查到最后往往是很小的一处差异，前面那些复杂猜测可以先放一放。改完隔一天再看一次，当场正常不代表能稳住。

测试环境和线上的差别，往往就在版本号和那几行被忽略的配置上。

处理上按这个顺序：先找出流程里能独立命名的步骤再拆；把共享的中间结果收成一个上下文对象；每个方法只做一件事且参数不超过三个。

改完只确认一件事：拆分后主流程能一眼读完，单个步骤可以独立写用例覆盖。