【CSDN編者按】距離上次更新剛過了半年，微軟的「親兒子」Windows 10最近又發布了一版更新內容，然而剛一發布就曝出了嚴重的文件丟失問題，只能緊急叫停。從以前的三年一次，到如今的半年一次，顯而易見的是，壓縮的產品發布周期使得Windows性能大打折扣。如此不走心的低級錯誤，微軟究竟是怎麼做到的？不僅如此，近年來微軟每一次發布的更新都備受詬病——微軟為什麼如此執著於更新Bug？又為什麼沒有在測試階段發現這個嚴重的錯誤？在本文的作者看來，這些問題的根源在於微軟的開發流程太糟糕了：先集成未經充分測試的功能代碼，然後再慢慢解決所有問題。正是微軟的這種理念，才使得原本備受期待的Windows 10「淪落」到今天的地步。

以下為譯文：

微軟最近發布了 Windows 10 October 2018 Update，結果發布之後卻立馬曝出了嚴重的文件丟失問題，迫使其不得不暫停發行更新內容。目前，該問題已被修復且處於重新測試的階段，等待再次發布。

顯然，這已經不是微軟第一次在Windows功能更新時出現問題了，以前就發生過更新中存在重大的硬體不兼容等問題，但這次肯定是最糟糕的一次。雖然我們大多數人都知道備份的重要性，但實際上大量數據（尤其是家用個人電腦上的數據）都沒有真正備份過，這些數據的丟失後果簡直是災難性的。

1.Windows即服務

微軟對Windows 10寄予的厚望導致其開發方式發生了徹底的改變。

為更好地響應客戶和市場需求，並儘快將改進的新功能展現給客戶，微軟將Windows 10定位成Windows「最後」的一個版本，所有新的開發工作都將反映到Windows 10的更新中，並每年提供多次功能的更新——這個新的開發模型被稱為「Windows即服務」。在經歷了一些初步的摸索之後，微軟決定每年進行兩次功能更新，一次在4月，一次在10月。

這項努力並非沒有成功。微軟已經通過新模型提供了有用的新功能，所以用戶不必再等三年的時間才能進行新的版本升級。例如：有一個巧妙的功能可以在虛擬機中無縫運行Edge，藉以提供更好的保護，免受惡意網站的攻擊；Linux版的Windows子系統（WSL）可以讓Windows系統在本機運行Linux軟體，對開發人員和管理員來說無疑是個福音；與SteamVR兼容的VR功能、對遊戲性能的改善和暗色調主題都是很不錯的附加功能......但這些更新對於純粹的消費者來說好處可能不是很明顯。但即使整體改進變小了，目前的Windows 10肯定還是比三年前發布的版本更好得多。

如果Windows依然三年一更新的話，可能還要很久才能開發出WSL工具

這是一件好事，我甚至認為，如果沒有Windows即服務，那麼部分功能可能就無法完成（或者至少不能成功地完成）。例如，WSL的開發受到了用戶反饋的指導，WSL用戶告訴微軟他們發現的不兼容性，並幫助微軟優先開發新的WSL功能。我不相信WSL如果不是每六個月更新一次的話它是無法獲得現在這麼大的影響力的——畢竟沒有人願意花三年時間來等待一個小修復，只是為了讓他們的軟體包能夠正常運行......定期更新可以鼓勵人們報告錯誤，因為他們可以親眼看到這些錯誤得到及時的修復。

但是Windows即服務的問題出在了它的質量上。雖然沒有明確的數據，但是很多主流的聲音都認為Windows 10採用每月一次的安全更新以及每年兩次的功能更新是一個瘋狂之舉。這樣的抱怨一直都存在，在Windows 10發布後不久，其bug不斷的更新內容就引起了廣泛詬病。

最近的這次數據備份問題就又把微軟的更新模式推向了風口浪尖，有評論說，每年兩次功能更新太過於頻繁，應該減少至一次，而且微軟需要停止開發新功能，應該專註去修復它的各個bug。事實上，很多人都在擔心微軟的頻繁更新會損害大家的信任，但其實一些用戶可能已經完全喪失掉信任感了。

這也不是第一次有人呼籲微軟放慢功能的更新速度了。他們擔心IT和消費者領域的用戶會因為這種「自殺性」的更新出現大面積的流失，隨著這次更新出現的低級錯誤，這種呼籲顯得尤為緊迫。

2.問題不在於更新頻率，而在於更新方法

但是說微軟每年只應該發布一次更新而不是兩次、或者批評Windows即服務的想法，這類的看法其實沒有抓住要領——微軟的問題其實不在於發布頻率的多少，而在於開發流程上就出現了問題。

為什麼說這是個關於流程的問題，而不是時間線的問題呢？在發布計劃方面，我們可以通過其他軟體的做法了解可能出現的情況。

macOS、iOS和Android每年的更新不止兩次，因此從某種意義上說，微軟正在試圖超過它們。跟微軟有類似想法的廠商有很多：Ubuntu每年都會發布兩個版本；Google的Chrome操作系統，比如Chrome瀏覽器，每六周就會收到一次更新；除了操作系統領域之外，微軟的Office Insider計劃也是每月一次更新為Office用戶提供新功能，並且可以在沒有太多投訴的情況下實現這一目標，同時提供穩定的新功能和修補；Visual Studio團隊同樣可以為其開發環境和在線服務提供頻繁的更新......很顯然，微軟內部的部分團隊已經很好地適應了定期更新應用程序的做法。

微軟在努力超越本地軟體的世界，進軍在線和雲服務領地，我們可以看到，無論是在內部還是在其他領域，微軟都在朝著持續交付的方向前進。系統的每次更新在通過充分的自動化測試後，都會自動部署到產品伺服器上。

的確，鮮有項目像Windows一樣複雜。就比如Ubuntu，它可能包含有更多種類的軟體包，但它的優勢在於許多軟體包都可以作為獨立的單元開發。當然，Windows也確實包含許多單獨的組件，但微軟做了很多工作來解決這些問題。這也就導致了Windows的規模仍然異常龐大而且集成度異常高，而且在某些方面，Windows仍顯得非常古老。

這些因素肯定會讓開發Windows變得具有挑戰性，但是難道這些挑戰性是因為每年兩次的發行導致的嗎？——這一點尚不清楚，但是微軟確實需要正確的開發流程。

Windows 10大約在2015年發布（我所有的圖標在哪兒？哦，開始菜單？）

3.歷史遺留的流程

微軟尚未完全透露Windows 10的開發流程，但從看得見的流程（向Insider用戶發送新功能的方式，以及Insider用戶必須忍受各種bug）結合從公司內部收集到的信息來看，微軟的流程確實存在著很大的缺陷——這與當年每三年發布一次Windows時的流程有許多重要的相似之處，雖然現在時間跨度大幅度壓縮了，但是很多開發方法仍然沒有改變。

過去，產品發布周期為兩到三年的時候，微軟的流程分為幾個階段：設計和規劃、功能開發、集成和穩定。

設計和規劃大約需要4-6個月，集中編程需要6-8周，然後是4個月的集成（通常每個功能都在自己的分支中開發，因此必須將它們合併在一起）和穩定（也就是說：測試和bug修復）。在產品開發周期的過程中，各個階段的循環將重複2-3次；Windows有3次迭代，第一次是原型，接下來的兩次是真實的產品。階段的長度可能會發生變化，但基本結構在公司內部廣泛使用。

這個過程很顯然存在一些問題。

也許最引人注目的是，實際開發新代碼所花費的時間非常少：在整個三年一次的Windows發行期間只佔到了6-8周的時間。相對實際在產品上工作的時間來說，規劃和設計階段佔據了非常長的時間。

也正是因為這個原因，他們的流程不能稱之為「敏捷」。當將功能擺到客戶面前使用的時候，新功能已經融入了最終產品，因此很難根據反饋進行更改。

開發和改bug的分離也是一個問題：在開發和集成階段，軟體的可靠性和穩定性將會急劇下降。集成的功能根本未經測試（因為測試放在了後面的階段），而且功能之間也未曾相互使用過（因為它們都是在集成階段之前在各自的分支中單獨開發的）。

然後，在冗長的穩定階段通過測試，報告bug以及改bug，將混亂的軟體打造成可以接受的狀態。在這個過程中，產品的可靠性應該再次開始提高。

2015年Satya Nadella向全世界介紹了Windows 10

4.新世界並不那麼新穎

在新世界裡，我們看到微軟的整個開發周期需要7-8個月的時間。雖然兩次發行之間只間隔6個月，但在上一個周期結束之前下一周期就需要開始，所以每次「提前開始」的組重開，Insider用戶就知道又要分散精力了。

通常每次更新剛開始的時候都非常平靜，幾乎沒有明顯的變化，但是在接下來幾個月里會發生重大的變化，同時引入大量bug。在更新發布之前的一個月里，我們會發現變更的數量會急劇減少，而且人人都會更加關注修復bug而不是新功能。

正如上述微軟員工所描述的那樣，開發最後的幾個月分為一個「告訴」的階段，然後是一個月的「請求」階段。在「告訴」階段，大家告訴Windows的領導正在進行的更改，而且他們只能默認接受所有的更改。在「請求」階段，大家的狀態自動切換成拒絕，在這個階段只允許真正有必要的修改，通常每天只能做出儘可能少的幾個改動。

因此，例如，10月更新的第一個版本（代號RS5）已於2月14日發布給Insider用戶；而更新的穩定版本（RS4）直到兩個月後的4月16日才發布。在3月7日之前RS5並沒有收到任何重要的新功能，到了5月、6月和7月相繼增加了許多功能，一直到8月和9月才截至，所以這兩個月只有很小的修改。 8月份甚至刪除了一些小功能，因為無法在10月發布時及時準備好。

當然，這個過程並不是每次都完全一樣。例如，我們看到新功能在預覽版本中出現了幾個月。這表明隨著功能的開發，新功能的集成似乎發生得非常快，而不是在最後進行一次大融合。

5.質量出現了大跳水

但是微軟的開發過程也存在一些重要的相似之處。最重要的一點是眾所周知的代碼集成存在大量bug，以及在測試和穩定階段就急於解決實際問題。他們甚至明確承認這一點：在宣布新版本的預覽時，微軟警告說「開發周期的早期版本中所包含的bug可能會讓一些人很痛苦。如果這讓你感到不適應，你可以需要考慮切換到慢速通道。慢速通道發布的版本將繼續保證高質量。「

我們可以在RS5中看到過這方面的一個例子。去年10月的更新為OneDrive引入了一項新功能：佔位符代表存儲在OneDrive卻沒有下載到本地的文件。每當應用程序嘗試打開文件時，OneDrive將直接從雲存儲中獲取文件並將其保存在本地，而應用程序無需知道最初本地有沒有該文件。如果磁碟空間不足，那麼RS5可以讓用戶選擇性地從本地存儲中清除雲複製文件。

這是一個非常聰明且很有用的功能，可以無縫使用雲存儲。而且該功能的代碼是全新的，由一個內核驅動程序為雲同步代碼（用於下載文件和上傳更改）與文件系統中的佔位符提供了粘合劑。他們還提供了一個API（第三方可以將他們的代碼連接到同一系統，就可以提供他們自己的同步服務）。

Windows的預覽版本有一個綠色的死亡屏幕（不是藍色屏幕），很容易區分

大家都以為微軟會圍繞這些新代碼進行一系列測試，驗證它是否正常工作：創建文件，檢查是否正確同步，刪除本地副本留下的佔位符，打開文件獲取真正的文件，完全刪除文件，等等。這裡面包含一些圍繞文件和目錄的基本操作，在任何完善的敏捷開發過程中，所有的這些操作都需要通過測試來驗證其是否按預期工作，並確保API可以提供相應的服務。

另外，大家都認為凡是未能通過測試的變更都會被拒絕而不會被集成。這些代碼應該做到完善，應該通過相應的測試，才能合併到Windows主要的代碼中，更不能發送給beta測試者。

然而，事情並非如此！許多預覽版本都有一個bug，刪除同步到OneDrive的目錄會導致機器崩潰。所以這個bug不僅集成到了Windows代碼中，還發給了最終用戶......

6.測試應該在發布前進行，而不是發布後

這件事情向我們揭示了Windows開發過程中的一些基礎問題。這些代碼根本沒有通過任何測試（據我的了解這是真的，他們允許集成未經測試的代碼，儘管我希望這不是常態），或者測試失敗也是可以接受的，測試失敗並不會阻礙其他工作，而且允許開發人員集成已知無法正常工作的代碼。

雖然我們作為外人無法確切地知道具體情況，也許這兩種情況都有，但無論哪一種都不是好消息。

對於Windows中舊代碼的問題，倒是情有可原，這些代碼是在自動化測試真正得到認可前就開發出來了，而且它們很可能沒有任何真正的測試基礎架構。但是OneDrive佔位符不是Windows的舊代碼，它們是一套全新的功能。

我們可以原諒舊代碼未經測試，但是沒有充分的理由說新代碼不應該有一組可靠的測試來驗證基本功能？而且已知有缺陷的代碼在修復之前肯定不應該合併，應該單獨發給測試人員。

因此，Windows 10的開發仍然遵循類似於Windows 10之前的軌跡。隨著功能的合併，穩定性和可靠性都會下降。然後依靠測試和穩定階段解決問題，並將代碼庫重新打造成可以接受的狀態。

不充分的自動化測試和對測試失敗的忽視意味著Windows的開發人員無法確信改動和修復不會引發連鎖反應。這就是在「請求」階段突發出來的現象：隨著更新的最終確定，可以接受的變更數量必須非常低，因為微軟沒有自信將每個改動的範圍和影響相互獨立開。只有大規模嚴謹的測試基礎設施才能建立這樣的信心：你知道改動是安全的，因為所有測試都運行成功了。無論微軟針對Windows展開了怎樣的測試，僅靠這些測試根本無法建立這樣的信心。

但從其他方面來看，微軟似乎確實有這種信心。

他們確實有很多測試，據我的了解完整的Windows測試周期需要數周的時間。他們也確實在貫徹完整的測試周期——只是並不是針對實際發布的那個版本。2018年10月的更新就是一個例子：代碼建於9月15日，而發布在10月2日。無論是RS5的哪次構建經歷了完整的測試周期，肯定不是我們實際使用的那個，因為完整的測試周期需要太長時間。

這是一種矛盾的姿態。如果他們對後繼的代碼改動很有信心，相信不會破壞任何東西，就可以在舊一點的版本上運行完整的測試周期。而且如果微軟非常確信這些變化不會破壞任何東西，那麼就不必在「請求」階段嚴厲限制它們。

Windows 10本來可以是一台運行良好的機器

7.那麼正確的方法是什麼？

Windows的開發流程與真正的敏捷項目形成了鮮明的對比。

以Google為其廣告伺服器建立的流程為例：對Google來說，這是一個關鍵的基礎架構，新的開發人員說他們為了修復一個小bug改動了代碼，並看到這些改動在一天內進入了產品。當改動的代碼提交到代碼存儲庫時，它會自動重建並進行一系列測試。然後負責該代碼區域的開發人員會審查改動，接受改動，並將其合併到主代碼庫中，最後再經過重新測試後部署到產品中。

當然，這樣比有點不公平，因為發現bug的時候，雲服務可以很容易地回滾代碼變更。Windows系統中導致系統藍屏的改動卻很難撤消和恢復。但是，廣告伺服器畢竟是Google很關鍵的一項服務（畢竟這是Google主要的掙錢項目），而一個失誤就會導致數百萬美元的損失。Google在開發流程中採用了測試和自動化，這意味著剛剛進入公司的開發人員也可以參與這項服務的開發，並在幾個小時內將改動部署到產品環境中，並且有信心保證正確。

這兩家公司的開發思維方式有根本性的不同。在開發過程中新功能可能不穩定，但在將新功能合併到產品代碼之前，必須滿足非常高的質量標準。與其像微軟一樣採用「先合併bug，之後再慢慢修復」的方法，還不如確保代碼在合併之前就儘可能做到零bug。

雖然雲應用程序確實提供了一定的靈活性，但這種方法也可以在桌面軟體中使用。例如，Google Chrome中的工作流程可以用來比較。Chrome的開發和beta版分支確實偶爾會出現bug，但總的來說，他們的代碼質量始終可以達到「發布」的水平。實際上，Chrome團隊的工作原則是，即使是最新版本的代碼質量也應該達到發布的水平。你可以將Chrome的開發分支當成常規的瀏覽器，除了不同的圖標外，你可能永遠不會知道自己沒有使用「穩定」的分支。廣泛的自動化測試和審查流程保證了這一點：在整個開發過程中，Chrome的代碼質量很高，沒有我們在Windows上看到的質量下降和後續修補的工作。

Google還投資了基礎設施來實現這一目標。它有一個分散式構建系統，可以在一千個核心上構建Chrome，因此可以在幾分鐘內完成整個構建。有條理地使用分支可以讓合併變得更加容易和可預測。為了儘快發現bug和進行回歸測試，Google實施了大量功能測試和性能測試。這些測試都花了很大精力，也都是至關重要的，因為它們可以讓Google穩定且定期地發布Chrome。

8.Windows的開發流程一直都很糟糕

微軟新的開發流程按比例增加了編寫新功能所花費的時間，並縮短了穩定和修復這些功能的時間。如果剛開始時功能的質量很高，那麼在新代碼集成之前，測試基礎設施可以支持新代碼並提高標準，那就沒問題了。

但到目前為止，以Windows 10的經歷來看，微軟尚未開發出維持這種新方法所需的流程和系統。

問題在於，即使現在將發布次數減少到一年一次也無法徹底解決問題。我經常感覺人們用有色眼鏡回顧過去Windows開發的舊時代，但是，即使我們回顧Windows 7以及以前的時代，實際上也會看到與今天的情況非常相似的問題。通常的建議是：在Service Pack 1發布之前，不應升級到新版本的Windows。為什麼？因為一般最初的版本都是bug累累且不穩定的狀態，直到Service Pack 1才能解決大多數的問題。

不同之處並不在於新Windows開發流程比以前更糟了、或者舊方法提供的結果更好，現在是我們每年需要經歷兩次「等待Service Pack 1」的情況。在每次的更新中，微軟認為代碼對於企業用戶來說足夠好的時間點可能在距離最初發布功能更新後的3-4個月，也就是我們「新的」Service Pack 1的時間點。

因此，我們遇到了最糟糕的境地：

舊Windows開發方法下，新產品發布的第一天通常表現並不好。而新的Windows開發方法會讓我們每年經歷兩次發布，而不是三年一次。一年中的大部分時間裡，這個補丁發布之前的不穩定性都會陪伴在我們身邊。

這些問題產生的根本原因，正在於微軟糟糕的開發流程：先集成未經充分測試的功能代碼，然後再慢慢解決所有問題。無論是每三年發布一次，還是每六個月發布一次，對Windows和用戶來說都很不友好。

9.這並非Insider用戶的工作

除了糟糕的開發流程外，第二個重要問題是微軟測試的性質已經變了味。

微軟過去擁有大量專門負責測試的人員，每個功能都可以分配到相應的開發人員和測試資源。這些測試人員中的許多人都在2014年被辭退或調職，因為微軟認為負責創建功能的開發人員應該負責大部分測試工作。Windows Insider計劃還專註於數百萬用戶提供的大量非正式測試結果，這比任何Windows的beta計劃都要大得多。

雖然我們不確定舊的流程是否必然會導致數據丟失的bug，專門負責測試的人員也有可能不會測試數據被刪除的特定場景。但是很明顯，微軟付出了大量精力用於處理Insider計劃中非專業測試人員報告的bug。其實有人在這次十月份更新發布前的三個月就報告了數據丟失的bug，但很多關於該漏洞的報告本身質量就很差，不僅缺乏必要的細節，還會使用不恰當的術語，最終微軟也只是忽略性地推出了「殘缺」的更新版本。

當然，微軟也未能在三個月內發現問題，那麼即使加長開發周期也未必會有顯著的改善——只是意味著bug被忽視的時間會從三個月延長到六個月。

微軟也有承諾要改變Insider的反饋流程，允許bug報告者指出問題的嚴重性，從而讓這些問題引起更多的關注。如果參與Insider計劃的用戶能夠正確地使用嚴重性指標，那可能會有所幫助，但似乎並不足以解決其核心問題——太多質量低下的bug報告了，龐大的處理量下微軟又怎麼高效篩選？

這就與代碼的質量問題密切有關。Insider計劃的真正優勢在於硬體和軟體的多樣性，它可以向外界暴露Windows，消除兼容性bug和驅動程序問題等等。然而，Insider的用戶不應該成為「這個功能是否可以真正工作」測試的主力人員。但是，感覺這就是微軟自以為「明智」的做法。

更糟糕的是，開發過程中代碼質量確實出現了下降的事實，意味著預覽版本一般都不適合個人電腦的日常應用。原因很簡單，它們不夠穩定。這會反過來貶低了Insider用戶測試的價值：實際上，Insider用戶並不會在所有的硬體和軟體上使用新版本，因為他們並沒有在主要的機器和所有硬體和軟體上使用預覽版本。他們只會在使用較少的輔助機器和虛擬機上測試而已。

10.投資工具必不可少

在像Windows一樣複雜而龐大的系統內，建立類似於Chrome的測試基礎架構是一項艱巨的任務。雖然Windows有些部分可以作為獨立的組件廣泛進行測試，但許多部件只有在作為完整系統的集成部件處理時才能進行有用的測試。其中一些，例如OneDrive文件同步功能，甚至需要依賴於外部網路服務來運行——這項工作一點也不簡單。

Windows應該採納的原則是：

代碼應始終達到發布的質量，不是「經過幾個月的修復」，而是「現在、隨時可以發布」，這將是一個巨大的變化，但這是必要的。

從第一天開始，微軟就需要進入一種狀態：每個新更新都要達到產品的質量。功能更新不應該是一次大事件，用戶幾乎不會注意到。減少到一年發布一次、或每三年一次發布也達不到這樣的效果，而且也不會有絲毫的幫助。

微軟需要改變的是流程本身，而不是時間線。

原文：https://arstechnica.com/gadgets/2018/10/microsofts-problem-isnt-shipping-windows-updates-its-developing-them/作者：Peter Bright，負責為Ars提供微軟服務，包括編程和軟體開發，Web技術和瀏覽器以及安全性。他曾在大英圖書館數字信息保存部門工作，致力於恢復和保護數字數據。在空閑時間裡，他喜歡編寫軟體並偶爾為開源項目做貢獻。譯者：彎月，責編：郭芮

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