方法应命名清晰、职责单一、参数精简、提前校验、卫语句优先：如findActiveUserByEmail而非getDataFromDB，saveUserAndSendWelcomeEmail需拆分，用CreateOrderRequest封装参数，if(user==null)快速失败，主干留happy path。
方法写得清晰，关键不在代码多漂亮，而在别人（包括未来的你）一眼看懂它要做什么、怎么做的边界、以及能不能放心复用。命名和组织结构是两大抓手，不是风格问题，而是可维护性的基础设施。
方法名要像一句小句子：动词+名词+可选上下文
好名字不解释“怎么实现”，只说“干什么”。避免 get、handle、process 这类模糊动词，优先用业务语义明确的动作。
-
差： getDataFromDB —— 没说取什么数据，也没说用途
-
好： findActiveUserByEmail —— 动作（find）、目标（User）、限定条件（Active + ByEmail）全在名字里
-
好： calculateOrderDiscountForVIP —— 动作+对象+业务角色，调用时无需点进方法体就知其意
- 布尔方法统一用 is/has/can 开头，如 isValidLoginToken、hasUnreadNotifications
一个方法只做一件事，且这件事要有明确边界
判断标准很简单：如果方法名里出现“and”“or”“then”，大概率该拆了。比如 saveUserAndSendWelcomeEmail 就违反单一职责——保存是数据层的事，发邮件是通知层的事。
- 把复合动作拆成多个小方法，各自命名清晰，再由一个协调方法组合调用
- 提取重复逻辑为私有方法，哪怕只被调用两次——重点是消除语义重复，不是抠行数
- 避免在方法内部混用不同抽象层级：比如一边查数据库，一边拼 HTML 字符串，一边记录日志——这些应分属 DAO、View、Logger 层
参数精简 + 提前校验，拒绝“黑洞式输入”
参数超过3个就要警惕；全是基本类型或 String 更危险——容易传错顺序、含义模糊。别让调用方猜哪个 String 是 ID、哪个是 name。
- 封装相关参数为专用入参对象，如 CreateOrderRequest，字段名自带语义
- 方法开头用 Objects.requireNonNull 或自定义校验工具快速失败，不把空指针留到深层逻辑里爆发
- 避免布尔参数控制行为分支（如 loadUser(true)），改用两个明确方法：loadUserWithPermissions() 和 loadUserBasicInfo()
提前返回优于深层嵌套，用卫语句清理主干路径
把异常、边界、快捷路径的判断放在最前面，用 return 或 throw 快速结束，而不是层层 if-else 把核心逻辑缩在右半边。
- 先写 if (user == null)
throw new UserNotFoundException();
- 再写 if (order.isPaid()) return buildReceipt();
- 最后才写主业务逻辑——这样主干是“happy path”，干净易读
- 少用 else，尤其避免 else if 套娃；每个卫语句独立、互斥、意图鲜明
基本上就这些。不复杂但容易忽略：命名是给程序员读的接口，结构是给逻辑流划的车道线。写完一个方法，试着不看实现，只读方法签名和注释，就能准确说出它该返回什么、依赖什么、改变什么——那就过关了。
