微软“作死”Windows

【CSDN编者按】距离上次更新刚过了半年，微软的“亲儿子”Windows 10最近又发布了一版更新内容，然而刚一发布就曝出了严重的文件丢失问题，只能紧急叫停。

从以前的三年一次，到如今的半年一次，显而易见的是，压缩的产品发布周期使得Windows性能大打折扣。如此不走心的低级错误，微软究竟是怎么做到的？不仅如此，近年来微软每一次发布的更新都备受诟病——微软为什么如此执着于更新Bug？又为什么没有在测试阶段发现这个严重的错误？

在本文的作者看来，这些问题的根源在于微软的开发流程太糟糕了：先集成未经充分测试的功能代码，然后再慢慢解决所有问题。正是微软的这种理念，才使得原本备受期待的Windows 10“沦落”到今天的地步。

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

新世界并不那么新颖

在新世界里，我们看到微软的整个开发周期需要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月发布时及时准备好。

当然，这个过程并不是每次都完全一样。例如，我们看到新功能在预览版本中出现了几个月。这表明随着功能的开发，新功能的集成似乎发生得非常快，而不是在最后进行一次大融合。

质量出现了大跳水

但是微软的开发过程也存在一些重要的相似之处。最重要的一点是众所周知的代码集成存在大量bug，以及在测试和稳定阶段就急于解决实际问题。他们甚至明确承认这一点：在宣布新版本的预览时，微软警告说“开发周期的早期版本中所包含的bug可能会让一些人很痛苦。如果这让你感到不适应，你可以需要考虑切换到慢速通道。慢速通道发布的版本将继续保证高质量。“

我们可以在RS5中看到过这方面的一个例子。去年10月的更新为OneDrive引入了一项新功能：占位符代表存储在OneDrive却没有下载到本地的文件。每当应用程序尝试打开文件时，OneDrive将直接从云存储中获取文件并将其保存在本地，而应用程序无需知道最初本地有没有该文件。如果磁盘空间不足，那么RS5可以让用户选择性地从本地存储中清除云复制文件。

这是一个非常聪明且很有用的功能，可以无缝使用云存储。而且该功能的代码是全新的，由一个内核驱动程序为云同步代码（用于下载文件和上传更改）与文件系统中的占位符提供了粘合剂。他们还提供了一个API（第三方可以将他们的代码连接到同一系统，就可以提供他们自己的同步服务）。

虽然我们不确定旧的流程是否必然会导致数据丢失的bug，专门负责测试的人员也有可能不会测试数据被删除的特定场景。但是很明显，微软付出了大量精力用于处理Insider计划中非专业测试人员报告的bug。其实有人在这次十月份更新发布前的三个月就报告了数据丢失的bug，但很多关于该漏洞的报告本身质量就很差，不仅缺乏必要的细节，还会使用不恰当的术语，最终微软也只是忽略性地推出了“残缺”的更新版本。

当然，微软也未能在三个月内发现问题，那么即使加长开发周期也未必会有显著的改善——只是意味着bug被忽视的时间会从三个月延长到六个月。

微软也有承诺要改变Insider的反馈流程，允许bug报告者指出问题的严重性，从而让这些问题引起更多的关注。如果参与Insider计划的用户能够正确地使用严重性指标，那可能会有所帮助，但似乎并不足以解决其核心问题——太多质量低下的bug报告了，庞大的处理量下微软又怎么高效筛选？

这就与代码的质量问题密切有关。Insider计划的真正优势在于硬件和软件的多样性，它可以向外界暴露Windows，消除兼容性bug和驱动程序问题等等。然而，Insider的用户不应该成为“这个功能是否可以真正工作”测试的主力人员。但是，感觉这就是微软自以为“明智”的做法。

更糟糕的是，开发过程中代码质量确实出现了下降的事实，意味着预览版本一般都不适合个人电脑的日常应用。原因很简单，它们不够稳定。这会反过来贬低了Insider用户测试的价值：实际上，Insider用户并不会在所有的硬件和软件上使用新版本，因为他们并没有在主要的机器和所有硬件和软件上使用预览版本。他们只会在使用较少的辅助机器和虚拟机上测试而已。

投资工具必不可少

在像Windows一样复杂而庞大的系统内，建立类似于Chrome的测试基础架构是一项艰巨的任务。虽然Windows有些部分可以作为独立的组件广泛进行测试，但许多部件只有在作为完整系统的集成部件处理时才能进行有用的测试。其中一些，例如OneDrive文件同步功能，甚至需要依赖于外部网络服务来运行——这项工作一点也不简单。

Windows应该采纳的原则是：

代码应始终达到发布的质量，不是“经过几个月的修复”，而是“现在、随时可以发布”，这将是一个巨大的变化，但这是必要的。

从第一天开始，微软就需要进入一种状态：每个新更新都要达到产品的质量。功能更新不应该是一次大事件，用户几乎不会注意到。减少到一年发布一次、或每三年一次发布也达不到这样的效果，而且也不会有丝毫的帮助。

微软需要改变的是流程本身，而不是时间线。

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

作者：Peter Bright，负责为Ars提供微软服务，包括编程和软件开发，Web技术和浏览器以及安全性。他曾在大英图书馆数字信息保存部门工作，致力于恢复和保护数字数据。在空闲时间里，他喜欢编写软件并偶尔为开源项目做贡献。

译者：弯月，责编：郭芮

“

征稿啦”