为什么大部分软件开发都会遇到的一些“不能修复的BUG”？

开发人员和产品经理几乎每天都在和各种各样的 Bug 打交道。当一个特性以代码的形式进入产品的时候，就伴随着各种各样的Bug，直到发布之前，都会一直处于发现Bug、修复Bug的循环中。

出现了Bug就要修复，这似乎是再自然不过的事情，但是有时产品经理发现了 Bug 后，兴冲冲地去找开发人员修复时，得到的答复却是

“我知道这个错误,原因很清楚,但无法修复。”。

当收到此回复时,产品经理可能会想：当我知道原因的时候为什么我不能修复错误? 是技术性太强还是懒得修理？这不仅仅是个玩笑,对吧？

第一,由于发布在即,错误修复将产生不确定的后果。这种情况非常普遍,这也得到了产品经理和开发人员的认可。很多时候,不同开发人员之间的业务代码是相互交织的。虽然从产品的角度来看,修复一个bug只是局部的小问题,但在测试不足的情况下,开发者本身并不相信这种修改不会影响到其他地方,这是无数“血的教训”的警示。

其次,这个小Bug可能是被设计出来以隐藏一个大Bug的。有时,产品经理认为开发人员的产品与原设计之间存在偏差,即使是一个bug,但开发人员知道产品与设计之间存在差异,以避免一些“坑”（可能是系统或其他人的）,必须做出调整以避免引起更大的问题。它们的具体操作可以是使用一点颜色偏差来解决系统潜在的绘图问题,或者按照正常的实现方式在另一条操作路径上触发程序崩溃,因此添加了许多附加条件,使其成为小场景中的随机问题。

最后,让我们谈谈无法修改的“最佳”bug。一个产品的开发过程往往不是线性的,有些甚至变化非常频繁。在代码编写的问题上,每个开发人员都有自己独特的想法,并考虑到各种各样的设计和架构,他们在遇到各种难题后,学到了各种新奇的技巧,他们在程序代码中的表达,几乎让接受者难以理解其奥秘。为了安全起见,当遇到新问题时,后来者往往不愿意调整旧的逻辑,而是用自己的技巧解决各种奇怪的问题,如此反复,最后的代码已经到了只能看不能动，但程序又能基本正常运行的神奇境界。

产品测试感觉到的可能只是些小问题，比如某些 Bug看似换张图就能解决，却被告知不能修复。有些开发者敏锐度很高，在感觉“填坑”力不从心之时选择离开，在代码注释中留下一句“祝你好运”来勉励接手的人。