微軟的開發流程是否有問題？從Windows功能更新事故頻發說開去

作者 | Peter Bright

譯者 | 薛命燈

可以說，2018 年 10 月份的 Windows 10 更新並不是微軟最成功的一次更新。在推出更新後不久，就有用戶反應數據丟失，微軟不得不暫停發行更新。好在問題已經得到修復，目前正在重新測試，並等待重新發布。

這並不是第一次 Windows 功能更新出現問題——在之前的更新中就已出現硬體不兼容等重大問題——但這次肯定是最糟糕的一次。雖然我們大多數人都知道備份的重要性，但實際情況是大量數據（尤其是家用 PC 上的數據）都沒有進行備份，因此一旦數據被刪除簡直是災難性的。

Windows 即服務

微軟對 Windows 10 雄心勃勃，想要徹底改變 Windows 10 的開發方式。他們希望能夠更好地響應用戶和市場需求，能夠儘快將改進過的功能提供給用戶。他們把 Windows 10 看成是 Windows 的「最後」一個版本——之後所有的開發都將被視為對 Windows 10 的更新，並且每年會提供幾次功能更新。這個新的開發模型被稱為「Windows 即服務」。在經歷了一些初步的摸索之後，微軟決定每年推出兩次功能更新，一次是在 4 月份，一次是在 10 月份。

這一做法在一定程度上取得了成功。在新的開發模型下，用戶不再需要等待三年就能獲得原先只有在新的主要版本升級中才能獲得的功能。例如，在虛擬機中無縫運行 Edge，以便更好地防禦惡意網站的侵害。Windows Subsystem for Linux（WSL）能夠在 Windows 系統上運行原生 Linux 軟體，這對開發人員和管理員來說無疑是一個福音。對於純粹的消費者來說，Windows 10 更新所帶來的好處可能沒有那麼明顯，不過與 SteamVR 兼容的 VR 功能、改進的遊戲性能和暗黑主題，這些都是不錯的改進。雖然整體改進較小，但目前的 Windows 10 肯定比三年前發布的版本更好。

這是一件好事。我甚至認為，如果沒有 Windows 即服務，它的某些部分可能就無法完成（或者至少不能像現在這麼成功）。例如，WSL 的開發吸收了來自用戶的反饋，WSL 用戶向微軟反饋他們發現的不兼容問題，並幫助微軟優先開發新的 WSL 功能。如果不是每六個月推出一次更新，我不認為 WSL 能夠獲得這麼多的關注——沒人願意為一個小的修復等上三年。定期更新能夠激勵人們向微軟報告 bug，因為他們可以及時看到這些 bug 得到修復。

Windows 即服務的問題主要出在質量上。之前的功能和安全更新問題已經打擊了微軟對 Windows 10 更新策略的信心。人們普遍認為，Windows 10 每月安全更新的質量已經大幅下降，每年兩次趕鴨子上架式的功能更新也很瘋狂。用戶的這些抱怨長期存在。在 Windows 10 發布後不久，這些不可靠的更新就引起了人們的關注。

有評論員表示，一年兩次功能更新太過頻繁，應該減少到一次，微軟需要停止開發新功能，只需要修復 bug 就可以了。有些人擔心微軟在經過幾次更新之後會失去大量的用戶信任，對於一些 Windows 用戶來說，可能早就沒有信任了。

這並不是微軟第一次被呼籲放慢更新的速度——一直以來有人擔心會出現大量的 IT 用戶和消費者流失——但最近出現的更新問題讓這個呼籲變得更加緊迫。

這是方式問題，而不是頻率問題

但是，要微軟每年只推出一次更新或批評 Windows 即服務這種想法都沒能戳中要點。問題並非出在發布頻率上，而是微軟的開發流程出現了問題。

為什麼問題出在流程上，而不是在時間頻率上？

Windows 10 的一年兩次更新比 macOS、iOS 和 Android 來得更頻繁，從某種意義上說，微軟是在試圖超越它們。但這種發布頻率並不是前所未有的：Ubuntu 每年都會發布兩個版本，谷歌 Chrome 瀏覽器每六周就會推出一次更新。除了操作系統之外，微軟的 Office Insider 計劃每月為 Office 用戶提供新功能，並且可以在不產生太多投訴的情況下實現這一目標，提供穩定的新功能和修復。Visual Studio 團隊同樣為其開發環境和在線服務提供頻繁的更新。顯然，微軟內部的一些團隊能夠很好地為他們的應用程序提供定期更新。

從在線服務和雲服務方面來看，無論是在微軟內部還是在其他領域，都在逐步採用持續交付。系統更新在通過足夠的自動化測試之後就會被自動部署到生產伺服器上。

的確，這些項目都沒有 Windows 那麼複雜。Ubuntu 包含了很多軟體包，但好在這些軟體包是作為獨立單元進行開發的。Windows 也包含了很多單獨的組件，但它們的規模仍然異常龐大，集成方式也不同尋常。至少在某種程度上，Windows 已經非常老了。

這些因素讓開發 Windows 變得極具挑戰性——但至於讓每年發布兩個版本變得那麼不切實際嗎？這個很難說。我只知道，它需要的可能是一個正確的開發流程。

由來已久的流程

微軟尚未完全透露 Windows 10 的開發流程，但從開發流程的一些可觀察特徵以及從公司內部收集的一些信息來看，他們的開發流程存在缺陷——與之前三年發布一個版本的流程有很多相似之處。時間頻率變得更加緊湊，但很多開發方法都沒有改變。

在過去，當產品發布周期為兩到三年時，開發流程被分為幾個階段：設計和規劃、功能開發、集成、穩定。規劃和設計可能為期 4 到 6 個月，編碼時間為 6 到 8 周，然後是 4 個月的集成（每個功能通常都在自己的分支中開發，到最後必須合併在一起）和穩定（測試和 bug 修復）。在產品開發周期中，這些階段將被迭代兩到三次，對於 Windows 來說需要經過三次迭代，第一次是針對原型，接下來的兩次是針對真實的產品。階段的時間跨度可能會發生變化，但基本結構在公司內部得到了廣泛應用。

我們從這種流程中可以看出一些問題。也許最引人注目的是花在編碼上的時間非常少：一個 Windows 版本在三年內只有 6 到 8 周的編碼時間，而在規劃設計階段與產品成型之間的時間跨度卻非常長。這個因素足以說明這個開發流程並不那麼「敏捷」。在你將產品放到客戶面前時，新功能已經融入到最終產品中，很難根據反饋做出修改。

開發和 bug 修復的分離也是一個問題：在開發和集成階段，軟體的可靠性和穩定性會急劇下降。被集成的功能未經過全面的測試（因為測試是在後面進行的），並且從未相互使調用過（它們在進入集成階段之前都是在各自的分支中單獨開發的）。然後，通過測試、報告 bug 和冗長的 bug 修復階段，軟體才逐步成型。

新世界並不那麼新

在新的世界裡，我們可以看到微軟將整個周期變為七到八個月。雖然版本之間只間隔了六個月，但下一個周期的開始發生在上一個周期結束之前。

每次更新在一開始都很平靜，沒有明顯的變更，然後在接下來的幾個月會引入一些重大變更和大量 bug。在更新即將發布之前的一個月左右，我們會發現變更的數量急劇減少，他們開始關注 bug 修復而不是引入新功能。

正如微軟員工所描述的那樣，最後幾個月的開發被分為「告訴」階段和為期一個月的「詢問」階段。在「告訴」階段，Windows 負責人被告知需要做出哪些變更，並默認接受這些變更。在「詢問」階段，默認變成了拒絕。在這個階段，只允許真正有必要的變更，通常一天只有幾個變更。

例如，10 月份的第一個更新版本（代號 RS5）早在 2 月 14 日就已發布給內部人士，4 月份更新（RS4）的穩定版本在兩個月後推出，也就是 4 月 16 日。RS5 在 3 月 7 日之前沒有收到任何重要的新功能。在 5 月、6 月和 7 月增加了很多功能，而在 8 月和 9 月只做了很小的修改。8 月份甚至移除了一些小功能，因為它們未能為 10 月的發布做好準備。

流程當中肯定存在一些差異。例如，新功能會在預覽版本中存在幾個月時間。這表明新功能的集成似乎進行得更快，開發完成後就進行集成，而不是在最後來一次大融合。

質量急劇下降

但也有一些主要的相似之處。其中最重要的一點是集成帶有 bug 的代碼，然後在測試和穩定階段解決這些 bug。他們甚至明確承認了這一點：在發布一個新的預覽版時，微軟會警告說「開發周期的早期構建版本可能包含對某些用戶來說很痛苦的 bug。如果這讓你感到不舒服，可以考慮切換到慢速通道（Slow Ring），慢速通道將提供更高質量的產品」。

我們可以在 RS5 中看到這種例子。去年 10 月份的更新為 OneDrive 引入了一項新功能：使用佔位符表示存儲在 OneDrive 中但未被下載到本地的文件。當應用程序試圖打開文件時，OneDrive 將從雲存儲上獲取文件並將其保存到本地，應用程序不會知道這個文件最初在本地是不可用的。如果本地磁碟空間不足，將選擇性地從本地刪除從雲端複製的文件。

這是一個非常智能且有用的功能，可以無縫地使用雲存儲。這些代碼都是新增的，有一個內核驅動程序在雲同步代碼（用於下載文件和上傳變更）和文件系統中的佔位符之間提供了粘合劑，還提供了一組 API（第三方可以利用它們來實現自己的同步服務）。

我們期望微軟能夠對新代碼進行一系列測試，以便驗證它們是否能夠正常運行：創建文件，檢查是否能夠正常同步，刪除本地副本，留下佔位符，打開文件以便再次從雲端獲取文件，完全刪除文件，等等。有一些圍繞文件和目錄的基本操作，在敏捷開發流程中應該有測試來驗證所有操作能否按預期工作，並確保 API 能夠做它應該做的事。

另外，任何無法通過測試的代碼變更都不會被集成到系統中。這些有問題的代碼需要被修復，通過測試，然後才能被合併到主代碼中。

然而，事情並非如此：很多預覽版中都存在 bug，比如刪除一個已經同步到 OneDrive 中的目錄會導致機器崩潰。這個 bug 不僅被集成到了 Windows 代碼中，還被發給了最終用戶。

在交付之前進行測試，而不是之後

這無疑是在告訴我們一些有關 Windows 開發的基本信息。要麼代碼壓根就沒有經過測試（並且我被告知確實是這樣的，他們允許在沒有測試的情況下集成代碼，但我希望這不是常態），要麼測試失敗被認為是可接受的非阻塞問題，並且允許開發人員集成他們知道無法正常運行的代碼。對於外人來說，無法確切地知道哪種情況是真的——有可能是兩者的混合——但不管哪樣都不好。

Windows 比較舊的部分可能情有可原——它們是在真正認識到自動化測試價值之前的時代開發的，而且當時很可能沒有真正的測試基礎設施。但 OneDrive 佔位符是新開發的功能，我們可以原諒舊代碼未經測試，但並沒有充分的理由說新代碼不應該有一組可靠的測試來驗證其基本功能。並且已知存在 bug 的代碼在得到修復之前肯定不應該被合併，更不用說被發給測試人員了。

因此，Windows 10 的開發仍然在遵循類似於 Windows 10 之前的軌跡。功能被合併，但穩定性和可靠性卻在下降。測試和穩定階段被用來解決問題，並將代碼庫修復到可接受的狀態。

不充分的自動化測試或對測試失敗的忽視意味著 Windows 開發人員無法確信變更和問題修復不會產生波及效應。下面就進入了「詢問」階段：最終成為更新版本一部分的變更非常少，因為微軟對每個變更的影響範圍不太有信心。這種信心只會來自大規模嚴謹的測試基礎設施：你知道變更是安全的，因為所有測試都能成功運行。但不管微軟對 Windows 做了什麼測試，都不足以獲得這種信心。

但在其他方面，微軟似乎表現得確實有這種信心。微軟確實提供了很多測試，Windows 的完整測試周期需要數周時間。他們確實使用了完整的測試周期，只是沒有被用在實際要發布的構建版本上。2018 年 10 月的更新就是一個例子：代碼建於 9 月 15 日，然後於 10 月 2 日發布。不管是 RS5 的哪個版本經過了完整的測試周期，但肯定不是我們實際使用的那個版本，因為完整的測試周期太長了。

這是非常矛盾的。如果確實有信心隨後的代碼變更不會破壞現有的東西，那麼在稍舊的構建版本上運行完整的測試周期就沒有什麼問題。但如果微軟真的高度確信這些變更不會破壞任何東西，那麼就不必在「詢問」階段嚴厲地限制它們。

這才是正確的做法

與真正的敏捷項目形成鮮明對比，這才是關鍵之處。以 Google 廣告伺服器的開發流程為例。廣告伺服器是 Google 的一個關鍵基礎設施，Google 的開發人員表示，他們針對小 bug 的代碼修復可以在一天內被部署到生產環境。當修改的代碼被提交到代碼庫時，會自動進行重新構建並執行一系列測試。代碼所有者隨後對變更進行評審，然後接受變更，並將其合併到主代碼庫中，重新進行測試並部署到生產環境。

當然，這種比較有點不公平。對於雲服務來說，在發現錯誤時可以更輕鬆地回滾代碼變更。對於 Windows 系統來說，一個導致啟動藍屏的變更是難以撤消和恢復的。但是，廣告伺服器仍然是 Google 的一項非常關鍵的服務——這是 Google 收入的一個主要來源——一個糟糕的變更可能會損失數百萬美元。Google 開發流程中的測試和自動化意味著剛剛加入公司的開發人員很快就可以上手開發，並在幾小時內將變更部署到生產環境，並且充滿信心。

從根本上說，Google 的開發思維方式與微軟是不一樣的。新功能在開發階段可能是不穩定的，但在合併到生產代碼庫之前，必須達到非常高的質量標準。微軟則是「現在合併 bug，以後再來修復」。

雲應用程序確實具備一定的靈活性，而這種方法其實也可以用於桌面軟體。例如，Google 在 Chrome 方面也應用了類似的工作流程。Chrome 開發和測試分支確實偶爾會出現 bug，但總體來說，他們的代碼始終接近「可發布的質量」。實際上，Chrome 團隊的工作原則是即使是最新版本的代碼也應該具備可發布的質量。你可以將 Chrome 的開發分支作為常規的瀏覽器使用，除了圖標稍有不同之外，你可能永遠都不會知道你所使用的並非「穩定」的分支。大量的自動化測試和評審流程促成了這一點：在整個開發流程中，Chrome 的代碼都具有很高的質量，不存在 Windows 上的那種質量下降和後續維修工作。

Google 還在基礎設施上做了很多投入來實現這一目標。它有一個分散式構建系統，使用了一千個核心來構建 Chrome，因此可以在幾分鐘內完成整個構建過程。他們有條理地使用分支，讓合併變得容易和可預測。Google 提供了大量功能測試和性能測試，以便能夠儘快發現 bug 和功能回退。Google 為此付出了很大的代價，也因此能夠定期發布穩定的 Chrome。

Windows 的開發流程從未好過

微軟的新開發流程增加了用於開發新功能的時間，同時縮短了用於穩定和修復這些功能的時間。如果新開發的功能從一開始就具備很高的質量，並在集成新代碼之前提供測試基礎設施支持，那就沒有什麼問題。但到目前為止，Windows 10 的經歷告訴我們，微軟並不具備這種新方法所需的流程和系統。

問題是，即使將發布數量減少到一年一次也不能解決問題。人們總是透過有色的眼鏡看待 Windows 開發的舊時代。如果我們重新回到 Windows 7 及以前的日子，我們仍然會看到與今天類似的問題。在發布 Service Pack 1 之前，通常不建議升級到新版本的 Windows。為什麼不？因為初始版本有 bug，不穩定，並且直到 Service Pack 1 才會解決掉大多數問題。

不同之處並不在於 Windows 新的開發方式比以前更糟糕，或者舊方法提供了更好的結果，而是我們「等待 Service Pack 1」的時刻變成了一年兩次。通常在發布更新後三到四個月，微軟會再次發布他們認為質量更高的代碼，這也就是我們的「新」Service Pack 1 時刻。

我們進入了一個最糟糕的世界：在舊的 Windows 開發時代，發布的初始版本不夠好。在新的 Windows 開發時代，我們每年會看到兩次發布，而不是每三年一次。這個不穩定的 Service Pack 一直與我們如影隨形。

根本的問題在於，集成沒有經過充分測試的功能，破壞了代碼庫的穩定性，然後希望在以後解決所有問題，但這不是一個好的流程。Windows 每三年發布一次並不好，但即使是每六個月發布一次也好不到哪去。

這不是 Insider 的工作

第二個問題是微軟的測試方式。微軟曾經擁有大量專門的測試人員，每個功能都分配了開發人員和測試人員。這些測試人員中有很多在 2014 年被裁掉或重新分配到其他團隊，他們認為可以將更多的測試工作轉移給開發人員。Windows Insider 計劃帶來了大量的非正式測試——擁有數百萬成員，比任何 Windows 測試計劃都要多。

舊開發方法不一定就能夠捕獲造成數據丟失的 bug，或許專門的測試人員也測試不到導致數據丟失的特定場景。但很明顯，微軟正在努力處理由 Insider 非專家測試人員提出的 bug 報告。數據丟失問題在更新發布前三個月就已被提出。很多 bug 報告看起來質量很差，缺乏必要的細節或者使用了不恰當的術語，但如果微軟在三個月內都沒能發現問題，那麼即使更長的開發周期也不會有任何效果。更長的開發周期只能意味著 bug 將被忽略六個月而不只是三個月。

微軟承諾改變 Insider 反饋流程，允許 bug 報告者指出問題的嚴重程度，以便更多地關注這類問題。這或許會有所幫助，只要 Insider 恰當地使用嚴重性指標，但似乎仍然不足以解決因為質量太低而導致的大量 bug。

這與代碼質量問題有關。Insider 計劃的真正優勢在於硬體和軟體的多樣性，幫助消除兼容性錯誤和驅動程序問題，等等。然而，Insider 不應該成為測試的主力，但這好像就是微軟推出這一計劃的目的。

另外，開發階段的代碼質量下降意味著預覽版本通常不適合用於日常的 PC，因為它們不夠穩定。這反過來降低了 Insider 測試的價值：事實上，Insider 並沒有讓新版本運行在所有的硬體和軟體上，因為他們並沒有在他們的主要機器上使用構建版本，他們使用的是不常使用的輔助機器和虛擬機。

在工具上進行投入

為 Windows 這樣複雜和龐大的東西搭建一套類似 Chrome 那樣的測試基礎設施將是一項艱巨的任務。雖然 Windows 的某些部件可以進行獨立的測試，但很多部件只有在作為整體系統時才能進行有用的測試。其中一些，例如 OneDrive 文件同步功能，甚至依賴了外部網路服務，所以這絕對不是一件輕而易舉的事。

要讓 Windows 代碼始終保持很高的質量——不是「經過幾個月的修復」，而是「現在，隨時」——將是一個巨大的挑戰。但這是必要的。從一開始，微軟就應該讓每一個更新都具備符合生產標準的質量。在這個世界中，用戶升級到最新和最好的版本將是一個明智的選擇，而且可以放心地升級。功能更新不應該是什麼虛張聲勢，要讓用戶幾乎注意不到。一年發布一次或每三年發布一次並不會帶來這樣的效果，從來都不會。微軟需要改變的是流程本身，而不是發布頻率。

英文原文

https://arstechnica.com/gadgets/2018/10/microsofts-problem-isnt-shipping-windows-updates-its-developing-them/

今日薦文

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！