為什么有些BUG不能改？

無論是開發還是產品經理幾乎每天都在和各種各樣的BUG打交道。但是，為什么有些BUG是不能修改的呢？

當一個特性以代碼的形式進入產品的時候，就伴隨著各種各樣的BUG，直到發布之前，都會一直處于發現BUG，修復BUG的循環中。出現了BUG就要修復，這似乎是再自然不過的事情了。但是，有時產品經理發現了BUG后，興沖沖地去找開發修復時，得到的答復卻是“這個BUG我知道，原因也清楚，但是不能修復”，簡言之就是知錯不改。

得到這個答案時，產品經理可能會丈二和尚摸不著頭腦。為啥連原因都知道的BUG卻不能修復呢？是技術含量太高還是懶得修復？除去開發就是想忽悠你的這種情況，我們來看看這其中的原因。

發版在即，BUG修復會產生不確定的后果。這種情況比較常見，也是產品和開發都認同的，原因還是簡單說說。可能作為產品經理在這個版本只負責一個特性，但很多時候開發之間的代碼是糾纏在一起的，可能從外面看修復一個BUG似乎只是這個產品特性自己內部的問題，但如果在測試不夠充分的情況下，開發自己都沒有信心保證這個修改是否會對其它地方造成影響，這是無數次血的教訓換來的謹慎。

用一個小BUG來隱藏一個大BUG。這種就是比較高級點了，有時你可能覺得開發做出來的樣子似乎和最初的設計有些偏差，這就算是BUG了，但開發卻是為了避開某些的坑（有可能是系統的，也有可能是別人的）不得已的調整，其實他心里知道和設計有出入，但是如果不這樣做，可能會引發更大的問題。

比如，用一點顏色上的偏差來解決系統可能出現的繪制問題，又或是按照正常實現方式會觸發一個別的操作路徑上的crash，于是開發就添加了很多額外的條件讓它成為一個只有小場景下隨機出現的問題。可是不巧，你剛好又遇到了。

最后來說說不能修改的BUG中的極品。

一個產品的開發往往不是固定的，有的變更甚至是非常頻繁的，而在寫代碼這個問題上，每個開發都有自己獨特的思想，每個剛踏入此坑的開發都懷著各種設計，各種架構。但是，現實往往是在遇到各種難以解決的問題后學會了各種奇技淫巧，這種奇技淫巧在程序代碼中的體現往往是“神來之筆”，原作者離開后，接手者幾乎難以理解其奧妙。

為保險起見，在遇到新問題時，后來者往往不愿意去調整舊的邏輯，而是開始施展自己的奇技淫巧去解決各種奇葩的問題，如此反復，最后的代碼已經到了只能看不能動，但程序又能基本正常運行的神奇境界。在產品體驗時感覺到只是有些小問題而已，比如看似僅僅換張圖就能解決的bug卻被告知不能修復。有些開發敏銳度很高，在感覺填坑力不從心之時選擇離開，因為再不走可能要吃不了兜著走了，所以也只能在代碼注釋中留下一句“祝你好運”來勉勵接手的人了。

很多產品中都或多或少都存在這些問題，這些都是不鼓勵的做法，不過在開發人員時不時變動的情況下，誰又顧得了那么多呢？或許開發再告訴你BUG修復不了時，你不會感到疑惑而是心驚。

#專欄作家#

給產品經理講技術，微信公眾號（pm_teacher），人人都是產品經理專欄作家。資深程序猿，專注客戶端開發若干年，對前端、后臺技術略懂，熱衷于對新的科技領域的探索。

本文原創發布于人人都是產品經理。未經許可，禁止轉載。