控制方法行数和复杂度的核心是确保单一职责与逻辑清晰，50行是软上限而非硬性限制；应通过提取子方法、空行分段、卫语句降嵌套、策略模式解耦等手段持续重构。
控制方法行数和复杂度不是为了凑数字，而是为了让每个方法真正“说清楚一件事”。行数只是表象，背后是职责是否单一、逻辑是否线性、读者能否一眼抓住重点。
方法长度以 50 行为软上限，但核心看职责边界
Java 编程规范普遍建议单个方法不超过 50 行——这不是硬性红线，而是提醒你：一旦接近这个长度，大概率已混入多个关注点。比如一个订单处理方法里同时做参数校验、库存扣减、积分计算、消息推送、日志记录，哪怕只有 48 行，也已违背单一职责。
- 把校验逻辑提取为 private boolean isValidOrder(Order order)
- 把库存操作封装成 inventoryService.deduct(order)
- 把日志统一收口到 logOrderProcessed(order)
拆分后主方法可能只剩 12 行，逻辑脉络清晰，各子方法也便于单独测试和复用。
用空行和语义分段代替“堆在一起”
即使总行数没超限，挤在一块的代码仍难读。空行是零成本的视觉锚点，能自然划分逻辑区域：
立即学习“Java免费学习笔记（深入）”；
- 参数校验完成后空一行
- 主业务处理块前后各留一行
- 结果封装、异常兜底、日志输出等收尾动作单独成段，前面加空行
例如：
// 校验参数
if (order == null) throw new IllegalArgumentException();
if (order.getItems().isEmpty()) return OrderStatus.INVALID;
// 执行核心流程
processItems(order);
updateStock(order);
sendNotification(order);
// 返回并记录
log.info("Order {} processed", order.getId());
return OrderStatus.PROCESSED;
圈复杂度比行数更值得警惕
一个 30 行的方法如果嵌套 4 层 if-else 或含多个 switch-case，其理解成本远高于一个 60 行但线性执行的方法。圈复杂度（Cyclomatic Complexity）超过 10 就该预警。
- 用卫语句（guard clauses）提前返回，减少嵌套层级
- 把长条件表达式抽取为有含义的布尔方法，如 isEligibleForPromotion()
- 多分支逻辑优先考虑策略模式或状态模式，而非巨型 switch
重构不是终点，而是日常习惯
方法变长往往不是一蹴而就，而是随着需求迭代慢慢“长胖”。每次加新逻辑前，先问自己：
- 这段代码和已有逻辑是否属于同一责任？
- 它是否可被其他场景复用？
- 如果删掉这部分，主方法是否依然语义完整？
答案是否定的，就该立刻提取。重构不是等代码腐烂后再大动干戈，而是小步快走、持续清理。
