工作中反复出现的问题总结
一、接收任务和沟通阶段
- 别人讲话时没有认真听，导致对方重复说明
存在的问题：
别人交代任务时容易漏听、忘记。
没有及时做好笔记。
经常让别人重复说明，容易让对方觉得烦躁。
沟通时经常说"对对对对"，显得比较急躁。
以后应该这样做：
别人讲话时先认真听，不要急着回答。
重要内容马上记录下来。
如果是口语说的 用手机录音或者 听完以后及时记录下来
没听懂的地方，等对方说完后再统一确认。
回应时小声说"嗯""好的""明白"，不要连续说"对对对"。
对方发送的需求文件、说明文档和附件一定要全部查看。
二、需求确认阶段
- 没有先整理完整需求，就直接开始开发
存在的问题：
对需求的整体目标没有完全理解。
需求发生变更时，没有把变更部分单独拆出来确认。
开发过程中才发现自己的理解和对方不一致。
以后应该这样做：
先用自己的话整理一遍完整需求。
明确本次需要新增、修改和不需要修改的内容。
如果需求有变更，只把变更的部分拆出来再次确认。
确认输入参数、输出结果、异常情况和影响范围。
确认清楚以后再开始写代码。
三、开发前的代码分析阶段
- 修改旧方法前，没有先判断方法的使用范围
存在的问题：
没有确认方法是公共方法还是私有方法。
直接修改公共方法，可能影响其他模块。
没有分析这个方法被哪些类和接口调用。
没有确认修改后返回结果是否会发生变化。
以后应该这样做：
先确认方法是公共方法还是私有方法。
查看方法被哪些类、接口和业务模块调用。
分析方法的入参、返回值和原有业务逻辑。
使用 AI 辅助分析：
这个方法是做什么的；
被哪些地方调用；
修改后会影响哪些文件；
是否会影响其他业务模块。
如果是公共方法，优先考虑新增方法、增加可选参数或者兼容旧逻辑，不要直接破坏原有功能。
例如需要根据项目 ID 筛选时，要确认是否会影响原来没有项目 ID 条件的调用方。
四、数据库和数据规范阶段
- 业务表 ID 没有统一使用平台框架的生成方式
存在的问题：
部分业务表使用了自己生成的纯数字字符串 ID。
没有确认平台框架是否已经提供统一的 ID 生成规则。
不同表的 ID 格式可能不一致。
以后应该这样做：
新增业务表之前，先查看平台现有表的 ID 生成方式。
确认是否可以使用平台框架提供的雪花 ID、主键生成器或统一 ID 工具。
不要随意自己拼接或者生成纯数字字符串。
如果必须使用纯数字字符串，要先确认：
字段长度是否足够；
是否可能重复；
前端是否会丢失精度；
是否符合项目规范。
已经存在的不规范 ID，需要先评估数据和接口影响，再决定是否修改。
五、Git 分支和项目文件阶段
- 开发时没有严格按照分支流程操作
存在的问题：
可能直接在 main、master 或 develop 分支修改代码。
开发前没有拉取最新代码。
没有为每个需求创建独立的 feature 分支。
标准流程：
拉取最新的 main、master 或 develop 代码。
从最新代码创建自己的 feature 分支。
所有需求代码都在 feature 分支开发。
开发完成后提交并推送远程分支。
创建 Merge Request，审核通过后再合并。
必须记住：
不要直接修改 main/master，不要在公共分支上直接开发。
- 新项目提交时，把无关文件也提交了
存在的问题：
没有区分源代码文件和编译生成文件。
可能把 target、日志、临时文件、IDE 配置等内容提交到 Git。
没有提前配置好 .gitignore。
新项目通常需要提交：
src 目录；
pom.xml；
Maven Wrapper 文件（项目使用时）；
配置文件；
数据库脚本；
README 和项目必要文档；
项目启动所需的其他源文件。
一般不应该提交：
target；
日志文件；
临时文件；
本地上传文件；
本地缓存；
本地个人配置；
IDE 无关配置；
包含密码、密钥和私人地址的配置文件。
提交新项目之前必须先检查 .gitignore。
六、编码和配置阶段
- Redis 数据没有设置合理的过期时间
存在的问题：
Redis 中的数据被永久保存。
没有根据业务场景设置 TTL。
长期运行后可能造成无效数据堆积和内存占用。
以后应该这样做：
使用 Redis 前先确认数据的生命周期。
验证码、临时状态、登录信息和缓存数据必须设置过期时间。
不要默认永久保存。
只有明确需要长期保存的数据，才可以不设置过期时间。
设置后需要检查 TTL 是否正确生效。
七、本地测试阶段
- 开发完成后没有进行完整自测
存在的问题：
写完代码后没有启动项目验证。
没有使用 Apifox 测试接口。
只测试正常情况，没有测试异常和边界情况。
没有确认旧功能是否受到影响。
以后应该这样做：
本地启动项目，确认项目能够正常运行。
使用 Apifox 测试接口。
检查正常参数、空参数、错误参数和边界数据。
检查数据库数据是否正确。
检查日志中是否存在异常。
修改公共方法后，还要测试原有调用方。
确认没有影响其他模块后，才能提交代码。
八、文档处理阶段
- 接口对接文档没有按要求整理和转换
存在的问题：
接口文档格式不统一。
对外发送前没有转换成 PDF。
文档内容可能缺少接口参数、示例和说明。
以后应该这样做：
检查接口地址、请求方式、请求参数和返回参数。
补充请求示例、返回示例和错误码。
检查文档是否包含敏感信息。
确认内容无误后，将接口对接文档转换成 PDF。
打开 PDF 再检查一次排版、分页和内容是否完整。
九、代码提交阶段
- 提交代码时存在文件遗漏或误提交
存在的问题：
没有检查 IDE 中标红或变红的文件。
有些修改过的文件忘记提交。
有些不相关的文件被一起提交。
没有查看实际代码差异就直接 push。
提交前必须执行：
查看 IDE 中变红、变蓝或有修改标记的文件。
执行 git status，确认所有修改文件。
执行 git diff，逐个检查代码变化。
检查是否漏提交必要文件。
检查是否误提交 target、日志、配置密码等文件。
确认代码能够编译和启动。
完成接口自测后再执行 commit。
commit 信息要写清楚本次修改内容。
push 到自己的远程 feature 分支。
十、创建 Merge Request 阶段
- MR 信息填写不完整或错误勾选选项
创建 MR 时应写清楚：
本次需求是什么；
修改了哪些模块；
主要修改内容；
是否修改数据库；
是否修改配置文件；
自测了哪些接口；
是否存在风险和注意事项。
以下两个选项都不要勾选：
Delete source branch when merge request is accepted
含义：
合并请求被接受并合并后，自动删除当前源分支。
当前工作规范：不要勾选。
Squash commits when merge request is accepted
含义：
合并时把分支上的多个 commit 压缩成一个 commit。
当前工作规范：不要勾选。
每个需求的标准开发流程
以后每次开发按照下面的顺序执行：
查看对方发送的全部需求文件和附件。
认真听需求并做好笔记。
用自己的话整理完整需求。
单独确认需求变更部分。
确认业务范围、接口和数据规则。
分析现有代码和公共方法的影响范围。
拉取最新 main、master 或 develop 代码。
创建自己的 feature 分支。
在 feature 分支上开发。
检查数据库 ID 和项目编码规范。
检查 Redis 等缓存是否设置合理的过期时间。
本地启动项目。
使用 Apifox 完成接口自测。
测试正常、异常和边界情况。
查看 git status。
查看 git diff。
检查是否存在漏提交或误提交文件。
执行 commit。
push 到远程 feature 分支。
创建 MR，写清修改内容和自测情况。
不勾选删除源分支和压缩提交。
等待代码审核和合并。
最需要记住的几句话
先听清楚，再记下来；先确认需求，再开始开发。
修改旧代码前，先分析调用关系和影响范围。
不要直接修改 main/master，不要不自测就提交。
提交前一定检查 git status、git diff 和所有变色文件。
每个需求发送的文件和附件都必须查看