5.8 KiB
后端开发反思报告
请参考
REPORT_GUIDE.md了解写作要求。建议 800–1500 字。
1. 我遇到的最大挑战
本次开发中，我遇到的最大挑战是JWT认证过滤器与实体类方法不匹配引发的代码标红及功能失效问题。在整合 JwtAuthenticationFilter 与 User 实体类时，IDE持续提示 user.getRole() 方法不存在，即便我已确认在 User 类中定义了 role 字段及对应的 getter 方法。
起初，我将排查重点放在代码书写层面，反复核对方法名拼写与访问修饰符，甚至重新编写 getRole() 方法，但问题并未解决。随后，我又尝试排查Lombok插件的生效情况，同样无果。在走了诸多弯路后，我调整排查思路，先通过清除Java语言服务器缓存并重启IDE，排除了IDE缓存干扰的可能；接着将目光聚焦到实体类的实例化环节。经核查发现，测试代码中调用了三参数的构造方法创建 User 对象，但初始的 User 类仅编写了无参和两参数构造方法，导致实例化后的对象未正确初始化 role 字段，进而使IDE误判 getRole() 方法无效。
找到问题根源后，我在 User 类中补充了包含 username 、 password 和 role 的三参数构造方法，同时确保 getRole() 方法的访问修饰符为 public 。修改完成后，代码标红消失，JWT过滤器也能正常提取用户角色并完成权限认证流程。
此次问题排查让我深刻认识到：后端开发中，实体类的构造方法设计与业务代码的匹配度至关重要。很多时候，代码报错的根源并非方法本身存在缺陷，而是对象实例化时的参数缺失。此外，IDE缓存问题是高频“隐形坑”，遇到代码标红时，应优先排除缓存干扰，再开展代码逻辑的排查工作。
2. 如果重新做一遍
回顾本次开发过程，若能重新设计系统，我会在数据模型设计与业务逻辑分层两个方面做出优化调整。
其一，优化用户角色的存储方式，采用枚举类替代字符串类型。本次开发中，用户角色直接以 String 类型存储，取值为 ROLE_USER 或 ROLE_ADMIN 。这种设计存在明显弊端：一方面，字符串手写输入易出现拼写错误，例如将 ROLE_ADMIN 误写为 ROLE_ADMINN ，会直接导致权限判断逻辑失效；另一方面，角色类型缺乏统一管理机制，新增角色时需要在多处代码中修改字符串常量，维护成本较高。重新设计时，我会定义 UserRole 枚举类，封装 USER 和 ADMIN 两个枚举值，在 User 实体类中使用枚举类型映射角色字段。这种方式既能借助枚举的强类型特性避免拼写错误，又能实现角色类型的统一管理，提升代码的健壮性与可维护性。
其二，拆分歌单复制功能的代码逻辑，提升代码复用性与可测试性。本次开发中，我将歌单复制功能的所有逻辑，包括原歌单查询、新歌单创建、歌曲复制等，全部集中在 copyPlaylist 这一个方法内，导致该方法代码行数过多，可读性与可维护性较差。重新设计时，我会遵循单一职责原则，将该功能拆分为三个粒度更细的方法： getOriginalPlaylistById() 负责查询原歌单并处理资源不存在的异常； createNewPlaylist() 负责构建新歌单的基础信息； copySongsToNewPlaylist() 负责将原歌单的歌曲复制到新歌单中。这种分层设计让每个方法只承担一项具体职责，不仅便于编写单元测试，还能在其他需要复制歌曲的业务场景中复用 copySongsToNewPlaylist() 方法。
3. AI 协同开发经验
在本次开发过程中，AI作为高效的辅助工具，为我节省了大量查阅资料的时间，但同时也暴露出一些局限性，让我总结出一套更高效的AI使用策略。
第一个典型场景是生成JWT服务类的核心代码。开发初期，我对JJWT库的API使用并不熟悉，于是向AI提问：“如何基于JJWT 0.11.x版本实现JWT的生成、解析与验证功能？” AI快速返回了完整的 JwtService 代码，包含 generateToken 、 extractUsername 等核心方法，其代码框架完全符合JJWT 0.11.x版本的使用规范，帮我省去了翻阅官方文档的时间成本。但深入核查后发现，AI提供的代码存在细节疏漏： isTokenValid 方法仅验证了用户名的一致性，未判断token是否过期，且未处理token解析时的异常情况。对此，我在AI代码的基础上，补充了 extractExpiration 方法用于判断token有效期，并通过 try-catch 块捕获解析异常，确保方法在token无效时能稳定返回 false 。
第二个典型场景是解决实体类构造方法不匹配的问题。当 User 类因构造方法缺失导致代码标红时，我向AI描述了问题现象，AI准确指出了核心问题——缺少三参数构造方法，并给出了正确的代码补充方案。但同时，AI附带了一个错误建议，即使用 new User(username: "admin", password: "123") 这种命名参数的写法，而这种语法属于Kotlin语言，并不适用于Java开发。我及时识别了该错误，未采纳此建议，而是按照Java的标准语法补充了构造方法。
基于以上两次使用经验，我总结出两点核心心得：大势所趋，不能不用AI，而且AI确实能帮助我们提升效率；但也不能全信AI直接照搬，它更适合当一个辅助工具，最终效果还得看使用者，尽信书不如无书。