正文
即使找到了，也通常不容易解决
最糟糕的莫过于，有时候难以验证是否已解决
如上，Debug并不是那么容易的事。
值得庆幸的是，大多数的bug都和上面图示的那样简单。因此，虽然海量的bug填满了程序员的工作时间，但软件项目仍然能跑。
至于能不能按时跑完，那就要看程序员的效率了。
一个程序员，效率的最大因变量，毫无疑问是个人能力。
如何提高自己的能力？这是程序员职业生涯中永恒的追求。本文避而不谈，只说程序员自己不能改变的一些外部环境因素。
注：本节的漫画图，来自于微信文章《
当我们在谈论bug时我们谈论的其实是
》。
第一定律：效率并不是时间的均匀分布
对于有正常生活规律的人来说，这条可以这么描述：
毫无疑问，debug是一项智力活动。头脑清醒的时候，效率最高；头脑不清醒的时候……嘿嘿……我们喜欢称之为埋雷。会不会在下一次以另一种形式，炸到自己或后面的人，这就管不了了，至少当前的这坑填了。
很多bug，不好好解决，就是这样
当今码农界，弹性工作制（免费加班）已经蔚然成风，996已成做项目的常态。
但是，朝九晚九，甚至到凌晨，真的能解决？请看上图。
晚上搞到精疲力尽，第二天的状态真的正常？请看上图。
周末仅休息一天，真的能不影响下周的状态？请看上图。
996，强行把早上变成了“晚上”，把晚上变成了“下午”。短期来看也许效果不错，但是长期下来，如果人员不流动，或者项目与项目之间有足够的间隙，那么必然整个团队都效率低下。并不是说解决的bug少了、慢了，而是让bug总量增多了。
八小时工作制
不仅仅是曾经的人文追求，也具备生物学上的合理。人，毕竟是一种周期性的生物。
第二定律：效率和程序员的心情正相关
一直以来，在文学和影视作品中，都宣称着：
