一个周天的下午，如坐针毡。为什么？因为明天周一了.... 要上班了，可能发bug要挨批评了。博客在git上维护：欢迎stargithub.com/MirroZhou/B…
最近的两次Bug:
- 做A需求的时候，看到以前的一段代码写的很难看，很不好维护，我忍不了了。所以麻（shou）利（jian）的修改了，然后我就狗带了~
- 做B需求的时候，要修改以前的代码，我在已有的函数上加了一个参数。然后我又狗带了~
发bug就像无孔不入的虫子，你以为你堵住了这个洞，但是它有在另外一个洞生长飞进来，防不胜防！
总结：导致发bug的原因往往不在新的功能和新的需求，而在你修改了以前的代码！！这些牵涉到的修改点，测试并不会去很仔细的测啊！！！！
以下是我们高工严厉指出并给我的建议并加上我的个人总结，与大家分享，定期踩坑更新（我希望再也不要更新了！！！）。
1. 修改前与原作者沟通
如果原作者还在，可以和原作者聊一下，最好他能讲一下代码结构，可以减少很多看代码的时间
2. 仔细阅读修改段落的上下文，并Get以下重点：
- 包括参数命名模式
- 注释风格等代码风格（分号啊，空行啊，空格啊.....）
- 参数定义位置（一般都在顶部）
- 函数定义方式（函数声明方式or 函数表达式方式）
- 代码结构（MVC分块）
get之后就按照已有的风格进行修改，也许你是一个很有风格的码农，你可以改变其他人一起用这个风格~
3. 开始修改了，以下雷请扫：
-
定义一个新的变量（函数）： 记得检查变量作用域并全局搜索~ 不要自信的觉得你和别人定义的不一样。
-
修改已有的函数参数： 不要修改参数顺序！！！！这样就算有些调用的地方你没有看到，也会降低很多的bug率。
4. review一遍代码，这里分为自己review和邀请其他人review。
- 自己review:
- 看是否有啥异常没有处理。前端经常犯错就是容错性不够好，毕竟从发起后台请求到你拿到数据，过程是多么艰辛。
- 修改了哪些点，尽可能记下来会影响哪些模块！！
- 他人review: 对于新人来很有用啊~
5. 提交测试
把自己会影响的模块列出来发给测试，这样他才知道重点啊~尤其是在写新需求夹带修改旧代码的时候！！ 这个很重要！！！ 如果有接入前端错误监控的话，关注一下报错内容。我们项目是有接入Badjs错误监控的。
6. 发布之后，你的产品有论坛或者群吗？
有的话直接加上去，观察用户反馈。往往这些地方是bug反馈最及时的~~~~~
总结完了，忐忑的去吃鸡然后默默等待明天批评。
