为什么有些BUG不能改？

　　无论是开发还是产品经理几乎每天都在和各种各样的BUG打交道。但是，为什么有些BUG是不能修改的呢？
　　当一个特性以代码的形式进入产品的时候，就伴随着各种各样的BUG，直到发布之前，都会一直处于发现BUG，修复BUG的循环中。出现了BUG就要修复，这似乎是再自然不过的事情了。但是，有时产品经理发现了BUG后，兴冲冲地去找开发修复时，得到的答复却是“这个BUG我知道，原因也清楚，但是不能修复”，简言之就是知错不改。
　　得到这个答案时，产品经理可能会丈二和尚摸不着头脑。为啥连原因都知道的BUG却不能修复呢？是技术含量太高还是懒得修复？除去开发就是想忽悠你的这种情况，我们来看看这其中的原因。
　　发版在即，BUG修复会产生不确定的后果。这种情况比较常见，也是产品和开发都认同的，原因还是简单说说。可能作为产品经理在这个版本只负责一个特性，但很多时候开发之间的代码是纠缠在一起的，可能从外面看修复一个BUG似乎只是这个产品特性自己内部的问题，但如果在测试不够充分的情况下，开发自己都没有信心保证这个修改是否会对其它地方造成影响，这是无数次血的教训换来的谨慎。
　　用一个小BUG来隐藏一个大BUG。这种就是比较高级点了，有时你可能觉得开发做出来的样子似乎和最初的设计有些偏差，这就算是BUG了，但开发却是为了避开某些的坑（有可能是系统的，也有可能是别人的）不得已的调整，其实他心里知道和设计有出入，但是如果不这样做，可能会引发更大的问题。
　　比如，用一点颜色上的偏差来解决系统可能出现的绘制问题，又或是按照正常实现方式会触发一个别的操作路径上的crash，于是开发就添加了很多额外的条件让它成为一个只有小场景下随机出现的问题。可是不巧，你刚好又遇到了。
　　最后来说说不能修改的BUG中的极品。
　　一个产品的开发往往不是固定的，有的变更甚至是非常频繁的，而在写代码这个问题上，每个开发都有自己独特的思想，每个刚踏入此坑的开发都怀着各种设计，各种架构。但是，现实往往是在遇到各种难以解决的问题后学会了各种奇技淫巧，这种奇技淫巧在程序代码中的体现往往是“神来之笔”，原作者离开后，接手者几乎难以理解其奥妙。
　　为保险起见，在遇到新问题时，后来者往往不愿意去调整旧的逻辑，而是开始施展自己的奇技淫巧去解决各种奇葩的问题，如此反复，最后的代码已经到了只能看不能动，但程序又能基本正常运行的神奇境界。在产品体验时感觉到只是有些小问题而已，比如看似仅仅换张图就能解决的bug却被告知不能修复。有些开发敏锐度很高，在感觉填坑力不从心之时选择离开，因为再不走可能要吃不了兜着走了，所以也只能在代码注释中留下一句“祝你好运”来勉励接手的人了。