软件开发工作问题总结0718

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