要多少天数就能复原bug，预先是很难晓得的，特别是假如你和这些标识符还新来的话，情况就更加诡异了。James Shore在《The Art of Agile 》一书中，明晰指出要想复原难题得先晓得难题的所处。而他们之所以无法准确估算天数是因为他们不晓得须要多长时间就能辨认出根本原因的所处，多于清楚这一点，他们就能合理估算复原bug所须要耗费的天数。不过，这个这时候恐怕莲藕都凉了。
很多bug都只需更动某一行标识符即可。但须要投入大批天数的是，后面还得指出怎么样才是恰当的——就像他们在钓的这时候，得晓得往哪里下饵，什么这时候鸟儿容易捉到等等。话说bug有三种类别：第二种易寻易复原，第三种难觅易复原，第三种易寻难复原，第三种难觅难复原。最意外事件的就是最后三型的，不但方敏仪，凄凄凉凉碧池，哪怕终于九死一生垂果，也只能在那边情不自禁地科泽县，无奈叹一句Daye。能这么说，假如是Lizier的标识符，不然让你找bug就跟峭腹一样——十藏，不晓得归属何种bug类别。
搜寻和复原bug
你晓得搜寻和复原bug意味着什么吗？要说，就是增容！不断的增容，许多次的增容！Paul Butcher透过大批组织工作，总结出以下形式化的关键步骤：
1.明晰目的。仔细翻查异常调查报告，确定是不是个bug，找寻各种有用的信息辨认出难题的根本原因，予以再现。再次检查是否与调查报告出现多次重复。假如出现多次重复，那看看曾经的相关人员是如何处理的。
2.准备组织工作——找寻恰当的标识符，用释明清扫组织工作区域。
3.相匹配试验环境。假如客户正在操作计算机配置，那么此过程能弹跳。
4.明晰标识符的用途，保证现有试验工具如常。
5.好了，现在能出发钓去咯——再现和诊断错误。假如你无法做到再现，那你就无法证明你已经完成复原组织工作。
6.撰写试验事例，或者透过整套的试验事例来捕捉bug。
7.进入复原模式——请亦须保证无法影响到其他任何人部分。但，在开展复原组织工作之前，可能你还要包办解构组织工作，因为多于这样，你就能肆无忌惮地鼓捣标识符。而且事前回归试验，还能保证你无法加入任何人捷伊bug。
8.整理标识符。透过一步一步解构，让你的标识符更易于理解，更安全。
9.找别人来审查一下，当局者迷旁观者清。
10.再次检查此复原过程。
11.试着不从主线出发，以检查这些bug是否会影响其他支线。合并这些变化，处理标识符中的差异，回顾所有的审查和试验等组织工作。
12.思考。好好想一想哪里错了以及为什么错了？为什么你的复原会起效？这种类别的bug还会出现在哪里？在《 The Pragmatic Programmer》一书中，Andy Hunt 和Dave Thomas也如是指出假如一个bug须要耗费你很多天数，那么一定要好好弄清楚原因。此外，还须要思考的是，怎么做就能吸取经验教训，将来在类似的难题上不再栽跟头？以及，他们采用的方法、使用的工具是否还有能改进的地方？以及这些bug的影响和严重程度。
找到bug，还是复原bug，哪个须要更多天数？
或许建立一个试验环境、再现难题和试验bug所需的天数，要远远多于找到bug和复原bug的天数。不过对于一小部分显而易见的bug，找到它们很简单——不过复原起来可能就不尽如人意了。
在《Making Software》一书中，有一章主要是探讨大部分的软件漏洞的来源，Dewayne Perry分析认为，相较于复原，辨认出bug（包括理解bug和再现bug）所需天数更长。有研究表明，大多数的bug（差不多有3/4）既易于辨认出又易于复原：5天或许更少（这是基于大规模实时系统透过重量级SDLC、大批审查和试验得出的数据）。但也有很恶心的bug，即便你能轻轻松松揪到它，还是还得呕心沥血就能复原好。
所以假如你打赌说你能很快复原bug，大多数情况下你还真没说错。不过当你打赌输了的这时候，那么，嘿嘿，就意味着你有大麻烦了。
所以，下次，boss再问什么这时候能复原bug，别再傻乎乎地回答马上就能搞定了。
