软件调试的生命周期

读大学时候，很少coding，更不习惯调试，嫌麻烦
工作后其实大部分都在调试，最近看了些书，所讲的软件调试过程大同小异
发现bug
记录
->重现bug->调查->提出修正方案->修改代码->测试验证->结束
跟瀑布模型一样，各阶段之间会迭代
发现和记录不是调试人员的工作
整个调查和解决过程才是软件调试的生命周期，关于调试，有些有趣的观点耐人寻味

“一旦我们开始编程，就会惊讶地发现让程序正常没想象中那么简单。调试不可避免。那一刻我认记忆犹新，当时我就意识到，从今往后我生活的大部分时间都要花在寻找自己程序的错误上面了。”
(莫里斯•威尔克斯 调试探索, 1949)

“调试难度本来就是写代码的两倍。因此，如果你写代码的时候聪明用尽，根据定义，你就没有能耐去调试它了。”
(Brian Kernighan，《C 程序设计语言》的作者之一)

“如果调试是除虫的过程，那么编程就一定是把臭虫放进来的过程。”
(Edsger W. Dijkstra)

1)bug发现的越晚，成本越高
2)花10%的时间coding，花90%的时间debugging
3)修bug跟补衣服差不多，越补越难看
4)越是后期发现的bug，越是难修
5)调试的时候会发现新的bug，修改代码后又带来了新的bug
还有些头疼的地方
6）test and debug，不停的测试与调试，却发现bug修不完
7) 如果用户描述的bug不能再现怎么办
8) bug不是很严重，但是要调试和测试，在环境搭建方面很困难，该不该修
9）修一个bug，不论简单与否，都要有白盒测试，黑盒测试，功能测试，回归测试，这么麻烦
10）如果bug修不了或者风险太大，有回避方法还好，如果没有怎么办？
......