为什么有些Bug不能改

开发人员和产品经理几乎每天都在和各种各样的 Bug 打交道。当一个特性以代码的形式进入产品的时候，就伴随着各种各样的Bug，直到发布之前，都会一直处于发现Bug、修复Bug的循环中。出现了Bug就要修复，这似乎是再自然不过的事情，但是有时产品经理发现了 Bug 后，兴冲冲地去找开发人员修复时，得到的答复却是“这个Bug我知道，原因也清楚，但是不能修复”。

得到这个答复时，产品经理可能会疑惑：为什么知道Bug的原因却不能修复呢？是技术含量太高还是懒得修复？不会只是想和我开玩笑吧？

首先，发版在即，修复 Bug 会产生不确定的后果。这种情况比较常见，也是产品经理和开发人员都认同的。很多时候，不同开发人员之间的业务代码是纠缠在一起的，虽然从产品的角度看，修复一个 Bug 只是修复一个局部的小问题，但在测试不够充分的情况下，开发人员自己都没有信心保证这个修改不会对其他地方造成影响，这是无数次“血的教训”换来的谨慎。

其次，这个小Bug可能是被设计出来以隐藏一个大Bug的。有时，产品经理觉得开发人员做出来的产品和最初的设计存在偏差就算是Bug，但开发人员知道产品与设计有出入，是为了避开某些“坑”（有可能是系统的，也有可能是别人的），不得已才进行了调整，以避免引发更大的问题。他们的具体操作可能是用一点颜色上的偏差来解决系统潜在的绘制问题，又或是按照正常实现方式会触发一个别的操作路径上的程序崩溃，于是添加很多额外的条件让它成为一个小场景下随机出现的问题。

最后来说说不能修改的Bug中的“极品”。一个产品的开发过程往往不是直线形的，有的甚至变更得非常频繁。而在写代码这个问题上，每个开发人员都有自己独特的思想，脑海里有各种设计和架构，现实中，他们在遇到各种难以解决的问题后学会了各种新奇技巧，它们在程序代码中的体现令接手者几乎难以理解其奥妙。保险起见，在遇到新问题时，后来者往往不愿意调整旧的逻辑，而是施展自己的技巧解决各种古怪的问题，如此反复，最后的代码已经到了只能看不能动，但程序又能基本正常运行的神奇境界。产品体验员感觉到的可能只是些小问题，比如某些 Bug 看似换张图就能解决，却被告知不能修复。有些开发者敏锐度很高，在感觉“填坑”力不从心之时选择离开，在代码注释中留下一句“祝你好运”来勉励接手的人。

很多产品中或多或少都存在这些问题，正常情况下当然都是不鼓励这样做的，不过在开发人员时不时变动的情况下，开发者也顾不了那么多了。