软件工程师在工作过程中，难免要解决软件中的各种bug,但是经常由于各种问题导致一个bug反反复复修改，甚至引出更多的bug。纠其原因，更多的是处理bug过程不规范导致的。笔者总结了工作中遇到bug的处理流程，如下：
一、bug确认
分配到一个bug后，要根据bug单号到bug管理系统查看该bug的详细信息。
1. 查看问题现象，了解问题
2. 查看软件版本和操作流程，检查当前版本和操作流程（步骤）是否有问题
此流程是为了确认是不是伪bug, 所谓伪bug,产生情况有两种，一是由于测试人员对操作流程或测试环境配置不正确产生的，比如未联网、口令输入错误等。
二是当前软件版本问题，如尚未支持该项功能
3. 检查是否是外部bug
根据日志分析，如果是其它模块问题引起的，转到其它模块负责人
4. 根据问题现象、日志确认是不是重复(已经提过的)bug
测试开的bug有可能是重复的，单从问题现象不一定看的出来，此时需要查看日志进行分析获得真正的原因所在，并与相似的bug作对比
5. 此时可以确认bug了，并在评论中增加问题的原因
二、bug修改方案确定
1. 确认修改范围
确定是否涉及协同修改（如模块（组间）接口修改）
2. 确定修改方案
如果需要协同修改，需要与其它模块（或组)相关人员讨论确定修改方案，讨论后，以邮件（附文档）发送给相关人员;否则自己（或与组内人员讨论）确定修改方案
3. 确定合入版本时间
确定修改方案后，需要与相关人员确定联调和进入版本时间，以免出现不同组合入版本时间不一致，产生其它功能问题，此处最好也以邮件形式通知确认
三、代码修改
根据确定的解决方案修改代码，修改过程中要时常关注以下关键点：
1. 是否影响函数接口的扩展性
2. 函数是否太大，是否需要拆分
3. 函数名称和实际功能是否有偏差，是否需要抽象成新的接口
4. 有无动态分配内存，内存使用后是否回收（包括goto和return场景）
5. 解决层面是否合适，是否有更好的修改点，比如更底层或更上层的修改
6. 是否会影响其它模块
7. 检查是否有死循环（循环条件是否正确）
8. 循环等算法是否有优化的必要
四、自测试
1. 先用修改前版本复现问题
2. 使用修改后的版本进行测试，确认解决问题
3. 对可能影响的功能进行回归测试
五、联调
如有必要，同其它组进行联调，确认正确修改问题
六、检查代码规范
根据代码规范检查生成的patch,修改使其符合制定的代码规范，参考如下：
1. 如空格/table问题
2. 未使用变量等
3. 是否有未初始化变量
4. 是否需要添加必要的注释
.........
七、代码提交
提交代码时，要注意以下几点：
1. 不要提交多余的文件
2. 不要遗漏新增加文件
3. 写上必要的提交信息，关联bug号
八、关闭bug
关闭bug, 关联相应的修改版本号，写上必要的修改说明
