前言
我刚出来工作的时候，一直逃避BUG，总会找借口说修复不了，后果可想而知。经历了几年的社会打滚经验，我在上级领导与其他同事的影响，逐渐慢慢的学会克服了各种一些我以为没办法修复的BUG，从而领悟出一些BUG解决经验。
延伸：
BUG分类
Software Defect （软件缺陷）≈ Software Bug （软件漏洞）
横向划分
- 业务逻辑缺陷
if-else / switch语句判断错误。
for 循环语句判断错误。
函数执行顺序错误。
注意异步操作问题。
- 技术缺陷
数据编码缺陷。
数据类型转换缺陷。
工具库 / 框架缺陷。
代码笔误缺陷。
代码性能缺陷。
软件配置缺陷。
软件运行环境缺陷。（Java/Nodejs/.Net/PHP/Python等各种软件运行环境版本）
软件系统环境缺陷。（Windows/Linux/Mac OS/Android/iOS等各种软件系统环境版本）
硬件设备环境缺陷。（CPU/硬盘/内存/网络/路由器）
注意IPV6与网络防火墙问题。
- 操作失误
软件权限。
软件打包。
软件版本号。
严格来讲，操作缺陷不算真正的软件缺陷，但操作失误也会导致软件产生意外缺陷。
纵向划分
- 优先级
紧急 > 高 > 中 > 低
BUG是永远修不完，BUG优先级划分，有利于研发人员利用合理时间去解决重要的BUG问题，而不是浪费时间去修复一些无关紧要BUG，导致自己的产品蒙受损失。
BUG修复
1. 复现问题
- 了解BUG的普遍性与特殊性。
找出在自己能正常运行应用，别人不能正常运行应用的问题。
- 了解BUG的复现步骤。
针对测试人员或用户的反馈步骤进行复现问题。
2. 定位问题
- 采用打断点方法。
在代码运行打断点，了解代码运行环节。
- 采用注释代码方法。
将代码一句句注释，来缩小BUG范围。
- 采用打印方法。
在代码打印出变量值、函数运行顺序。
必要时需要输出日志文件进行定位。
- 检查版本控制的历史代码。
检查自己代码是否被覆盖，是否存在冲突。
3. 修复问题
- 进行代码审查。
- 请教你身边的同事，上级领导。
不耻下问，不要不问。
- 将错误提示复制，到搜索引擎搜索。
延伸：
注意分析BUG的真伪性，确认是真正意义上的BUG才去修复，否则只会适得其反，BUG越修越多。
BUG管理
- 通过文档管理BUG。
- 通过项目管理系统软件管理BUG。
延伸：
反馈BUG的参考格式
时间： （年/月/日）
标题： （简单标题）
等级： （紧急 / 高 / 中 / 低）
描述： （详细内容）
环境： （软件系统环境/硬件设备环境/网络环境）
位置： （URL地址 / 应用页面）
截图/录像： （选填，产生BUG现象截图）
复现：（产生BUG操作步骤）
实际结果：（出现什么现象 / 问题）
预期结果：（应该是什么样 ）
是否修复：（是 / 否）
备注：（选填，如果不能修复软件BUG，补充说明原因）
如果实在无法修复严重的BUG，应该及时停用，减少不必要的损失与麻烦。
不建议在生产环境继续运行有严重的BUG的产品。
建议
BUG并不可怕，可怕是你自己不去克服它。
要相信自己，不要给自己找借口。
不要轻信自己的直觉，抱有质疑的态度。
冷静分析代码，大多数的BUG是可以修复的。
439
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
