微軟內部真的不允許程序員修復bug，除非造成的損失已經無可挽回了嗎？

01-07

微軟內部真的不允許程序員修復bug，

看是什麼階段的。Release之前的bug當然隨便修，Release之後要先申請批准，沒事不能擅自修bug。不過你執意要修當然也可以，會進新版本，不進舊版本，除非批准了。不過只要你肯一隻更新的話，那肯定不會遇到守著舊版本那麼多年沒人理你的事。

除非造成的損失已經無可挽回了嗎？

當然不是，批准一個bug的修復可以有很多理由。當然了財報的意見也是很重要的，花錢多的地方bug就比較重要。

要怎麼樣才可以讓老闆批准修一些對他自己價值不高的bug呢？

郵件轟炸，修中國區的bug都是這樣的，先拉一批人，然後每天騷擾一次。

對於已經發布的產品功能，要修一個bug一般會經過一個bug triage的過程，因為不是每個bug都是真bug，有的就是這麼設計的，有的是新功能需求。就算是真bug，也要看影響範圍和程度，有些bug修一修就要好幾天，所以優先順序肯定也要考慮的。還有些bug要修的風險很大，容易出regression，這個也得考慮。在未發布的新產品裡面修的成本就低了很多，因此基本上也是能修就盡量修，程序員自己看到了隨手就可以修，當然也不一定能修得完。

總之，這就是個如何利用有限資源創造更多價值的遊戲，bug triage就是一個決斷過程，不修某個bug也許就是個正確的決定。這個決定不在於是誰做的，而在於是否恰當。如果某個程序員自己做了個決定「私自」修了個bug，大部分情況下我也會相信他的決定並且給予鼓勵，即使這個決定不好也不是個大問題，敢做決定本來就是件應當鼓勵的事情。但如果他持之以恆地做出錯誤的決定，那作為boss肯定要找他談話咯。

不要把修bug搞成政治正確那樣好不好？

當然沒有這麼誇張。

bug就是bug，如果危險到一定程度（比如security相關），不可能會拖到出大事才修。

不過，如果產品已經發布，微軟（其實軟體公司都一個樣）在修bug時會傾向於保守。內部發現的，不易觸發，而且觸發也不會造成嚴重後果的bug的priority就會很低，時常堆積在bug資料庫里沒人理，或者乾脆標記為won"t fix關掉，除非有客戶抱怨才會修。

此外，如果產品已經發布，修bug的流程會繁瑣很多。因為需要避免regression，也就是修好一個bug又引入別的bug的問題。系統大到一定程度，已經沒有人能完全掌握了，regression的風險也會增加，因此對已經發布的產品修bug，code review和test流程多了很多，成本也就高了很多，所以只有嚴重的，或者客戶直接提出的問題才會修。

當然，如果出現緊急情況，bug修復可以加快很多。但這不是靠縮減流程，而是靠那些on call的碼農半夜爬起來全力處理。所謂洛杉磯凌晨4點的風景（好吧微軟是在redmond不過這不重要）就是如此。

當然微軟鹹魚員工最有發言權。

我講我從書上看來的一個小故事，講的是微軟如何極致追求前向兼容的。

windows 95發布的時候，為了維持對以前windows版本的前向兼容，微軟投入了大量的人力物力來修復前向兼容相關的bug。最最極端的一個例子就是,某個遊戲的bug剛好在windows升級到95的時候被觸發，就是這個內存泄露相關的bug在以前的版本上工作的好好的。但是到了windows95卻被觸發了。然後微軟居然在95的內核里加入了特殊的執行邏輯，如果檢測到時這個遊戲在運行，那麼就運行舊版本的內存分配器來保證對這個遊戲的前行兼容。

回到題目：微軟內部真的不允許程序員修復bug，除非造成的損失已經無可挽回了嗎？

也許現在是這樣的（其實我也不大相信）。不過有這麼一段時間，為了某種目的，微軟甚至會不予餘力的修復甚至都算不上是bug的bug。

很正常。微軟這種可不是互聯網。一天24次迭代更新，對於Windows、Office，這個是絕對不可能的。

此外，Windows、Office的複雜度遠超出想像。Fix了一個bug，搞不好就牽扯出其他幾個bug。而一個新bug發布出去了，影響的就是幾千萬人了。

綜合收益和風險，修bug要經過允許，是正確的。

不光在微軟，在其他企業和團隊也一樣。

修復 Bug 在用戶看來這樣天經地義的事，在其主家企業里卻是需要安排的，這太正常了。

簡單來說，因為大大小小的 Bug 日積月累下來，實在是太多了，而工程師精力不夠。畢竟，如果修這個 Bug 要花兩個小時，可這原本這兩個小時可以用來創造更有價值的產品。

工程師的是企業雇來的，其精力的投資方向也應由僱主企業說了算；同樣，產品也是僱主企業的，產品形態也應該由僱主企業說了算。是修這個 Bug 有價值，還是做別的事更有價值也應該由企業說了算。

就跟一些工程一樣

都快完工了你想到一個改進，但是不會有人採用的。

為什麼？

誰敢說這個改進就一定是好的？不會牽扯出來新的問題？重新驗證的成本誰承擔？

於是你這個改進只能放到下個工程或者下一代產品上，一次性統一驗證。

其實就是這樣，如果一個程序員有能力修一些複雜（但是不太重要）的bug，他肯定也有能力做一些更有價值的事情。

所以修不太重要的bug這件事，放到哪個公司，都沒人願意做。

很多時候軟體不是越改越好的，而是越改越差。在穩定版本上修復bug或者追加功能都應經過嚴格的評估。

除非是半成品就匆忙發布了。

正式發布之後根據嚴重級別來修復，放在哪裡都是一樣。

難道有哪家公司允許程序員自己修復bug嗎？？？

想起vld和mfc一起用時會報內存泄露，有人向ms提bug，ms的回答是因某些原因不好改決定不修這個bug。。有空再找鏈接吧

每天都在修bug的office員工路過，不過基本都是修dev版的。對於office這種3年才一次大release的產品來說，上個版本的bug基本留著不動，因為除了可復用的部分外，很多都會拋棄掉（講真，維護和我差不多大的代碼真是相當痛苦），而已經成product的要麼等更新（有幾率解決），要麼買一個版本的產品咯。

如果是web service/web app的話就不一樣了，畢竟改起來部署一下就好了，所以還是推薦用。

先說答案，不許修 bug 是為了向後兼容性。

這件事體現了微軟的價值觀：「向後兼容性」比「功能正確性」重要。

相比之下，Linux kernel的價值觀截然相反，每個小版本都會打破內核中的向後兼容性。

順便跑個題。如果你真的懂的什麼叫做向後兼容性的話，你就會發現 semver 有點荒謬。

semver 的規定是這樣的：

Given a version number MAJOR.MINOR.PATCH, increment the:

MAJOR version when you make incompatible API changes,

MINOR version when you add functionality in a backwards-compatible manner, and

PATCH version when you make backwards-compatible bug fixes.

但是我覺得世界上可能不存在 backwards-compatible bug fixes 這種東西。

比如說你以前調一個計算加法的庫，算1 + 1，返回3。現在庫升級了，返回2。這叫做 behavior change 。

正常的版本管理而已，說得跟什麼似的，知乎不是碼農多麼。

沒有回歸測試保證下的修改是有風險的，系統越大風險越大

修bug，不是抓臭蟲，搞掉一個是一個

是會有side effect

所以在已經release出去的產品中，當然只有那些priority高的，很有必要修的才修。

如果碼農想修啥修啥，在經過各種質量控制流程已經release出去的版本上，很容易出大問題，因為各種patch之類的測試，並沒有那麼完備

題主的問題，不在於不讓修，在於為啥貴bug沒有沒定位high priority

微軟向來是一個人的活，僱傭兩個人，然後每個人都要花三倍的精力去對付另外那個人。這樣每個人都有超額的工作量要完成了。於是，priority就成了至關重要的東西。你花時間去修random的bug，去給自己的feature做不必要的花邊彩蛋，或者甚至敢做一些有點挑戰性，最終很可能做不出來的工作，那都是給自己和老闆惹麻煩。