现在大多数需求，我都能够独立完成，也能够把业务流程转化成代码。但回头看自己写的代码，真正需要提升的已经不是语法，而是工程能力。

我把目前最需要训练的内容总结成两个阶段，以后每写完一个功能，都回来对照检查，不断补充。

---

第三阶段：把业务拆成清晰模块

这一阶段关注的是代码结构。

目标不是把代码写短，而是让每个模块职责单一、容易理解、方便复用。

我会检查下面几个问题

① 有没有重复逻辑可以封装？

例如：

• Redis Key 生成
• requestHash 生成
• 参数校验
• 查询条件构建
• VO 转换
• 通用工具类

如果一个逻辑以后还会出现第二次，就应该考虑封装，而不是复制。

---

② 有没有魔法字符串、魔法数字？

例如：

"price-list"
"tenant_id"
1
20

优先考虑：

• 常量
• 枚举
• LambdaQueryWrapper
• 配置项

减少硬编码。

---

③ 方法职责是否单一？

一个方法最好只完成一件事情。

例如：

生成请求指纹
检查额度
查询缓存
查询数据库
记录日志

如果全部堆在一个方法里，以后修改成本会越来越高。

---

④ 命名是否能够表达业务？

看到变量名，就应该知道它代表什么。

例如：

不要：

boolean b;
Object obj;
Map map;

尽量：

boolean saved;
UserApiQuota quota;
QueryApi apiConfig;

命名就是代码最重要的注释。

---

⑤ 注释有没有解释"为什么"？

不要写：

// 获取今天日期

因为代码已经说明了。

应该写：

// 每天使用不同 Redis Key，使第二天重新计算额度

注释应该解释设计原因，而不是翻译代码。

---

第四阶段：考虑并发、事务、异常、可维护性

这一阶段关注的是代码是否可靠。

很多 Bug，不是因为业务不会写，而是边界没有考虑完整。

我会检查下面几个问题

① 有没有异常情况没有考虑？

例如：

• Redis 查询失败
• 数据库更新失败
• 参数为空
• 配置不存在
• 第三方接口异常

不要只写正常流程。

---

② 数据会不会出现不一致？

例如：

数据库成功
Redis失败

或者：

Redis成功
数据库失败

写涉及多个系统的数据时，要思考：

哪一步失败以后，系统还能不能保持正确状态？

---

③ 有没有事务边界？

我要先问自己：

哪一步开始算真正成功？

例如：

• 请求进入接口就算一次？
• 查询成功才算一次？
• 返回成功才算一次？

业务规则确定以后，再决定事务边界。

---

④ 有没有并发问题？

凡是出现：

先查
再判断
再修改

都要问自己：

两个人同时执行，会不会出问题？

能用数据库条件更新解决的，就不要拆成多步。

---

⑤ 有没有资源没有释放？

例如：

• Redis Key 有没有过期时间？
• 临时文件有没有删除？
• 线程有没有关闭？
• 数据库连接有没有释放？

资源管理也是可靠性的一部分。

---

⑥ 有没有考虑以后维护？

每写完一段代码，我都会问自己：

如果三个月后回来修改：

• 我还能不能快速看懂？
• 别人能不能快速接手？
• 修改一个地方，会不会影响很多地方？

如果答案是否定的，就说明还可以继续优化。

---

我的代码检查清单

以后每完成一个功能，我都会快速检查下面这些问题。

结构

• 有没有重复代码可以封装？
• 方法职责是否单一？
• 有没有魔法字符串？
• 命名是否准确？
• 注释有没有解释原因？

可靠性

• 是否考虑了异常情况？
• 是否存在数据不一致？
• 是否需要事务？
• 是否存在并发问题？
• 临时资源是否释放？
• 三个月后的我还能快速看懂吗？

---

我希望自己达到的目标

以前，我写代码时更多关注的是：

这个需求能不能实现？

以后，我希望自己更多关注：

这段代码是否足够稳定、清晰、容易维护？

真正成熟的 Java 代码，不只是能运行。

它还应该做到：

• 职责清晰
• 结构简单
• 命名准确
• 边界明确
• 异常完整
• 状态一致
• 易于扩展
• 易于维护

这份清单会持续更新，每发现一个新的问题，就补充进来，让它逐渐成为自己的开发规范。