Linux 开发过程那么麻烦，是否值得？作者：GlauberCosta来源：架构头条Linu

作者：Glauber Costa 来源：架构头条
Linux 从诞生至今，已经快有 30 年了。这期间 Linux 一直延续着通过邮件来提交变更、审查、讨论直至批准的研发过程，这一流程非常费时费力，不仅成为新人的进入门槛，也成了可持续生产的障碍。那么，为什么 Linux 一直要坚持遵循这一过程呢，它能带来什么好处？存在哪些弊端？有什么解决办法吗？
文章插图
在早期，由 Linus 自己手工管理大家贡献的代码，不借助任何版本控制系统。而现在，已经使用 git 了。
然而，有一件事在整个过程中却从来都没有变过：代码被发送到一个（或多个）邮件列表中，然后直到做出最终判定之前，要进行一系列的审查和讨论。
尽管 Linux 是成功的，但这一过程却一直饱受诟病。微软的 Sarah Novotny 最近在社交媒体上发表了一篇文章，称 Linux 所使用的协作工具早已过时，如果这个社区想要吸引新鲜血液，最好换掉这些工具。
我认为我对此有一定的发言权：近十年来，我就在用类似的工作流程为 Linux 和其他项目编写代码。就职于 Red Hat 的时候，我为 core x86 基础设施、KVM 管理程序和 QEMU、Xen 管理程序和其他系统贡献过代码。虽然，我因为把主要精力投入到了 Seastar C++ 框架和 ScyllaDB 数据库上，在大约 7 年的时间里没有过多接触过 Linux ，但它们采用的开放方式却与 Linux 非常相似。现在我是一名 Datadog 公司的工程师，该公司遵循的流程与其他网络公司几乎完全不同。
那么我的立场是什么呢？首先，我的态度很明确：我不喜欢 Linux 的开发过程。我坚信，这一过程不仅是进入的门槛，是可持续生产的障碍（尽管并不是因为电子邮件），也是令人产生沮丧情绪的源头。我不打算在任何项目中遵循这一流程，如果我能决定这些项目怎么做的话。
但与此同时，似乎许多对 Linux 过程持批评态度的人认为，它的捍卫者之所以如此顽固地墨守成规，只是因为 Linux 充斥着一些不愿做出改变的坚守者。尽管我相信的确存在这样一些个别人，但事实上真正的原因并非如此。 Linux 所遵循的开发过程提供了一些独一无二的重要优势，这些优势对于任何其他组织也均有裨益。
除电子邮件以外，任何其他自以为是的工具化都会迫使 Linux 抛弃这些好处，大家不愿意舍弃的是这些好处，而不是电子邮件。工具化应可以降低进入的门槛，改正过程中那些令人沮丧的方面，同时能够让组织实现 Linux 所具备的真正推进软件开发的好处。
这样的优势有很多，但是由于时间的关系，我会着重来谈其中我认为最重要的那一个。我将尽最大努力向你解释它是什么，为什么尽管它有优点却又如此令人沮丧，为什么它只是对其他组织有益，但对 Linux 却至关重要。
1. 提交消息和补丁Linux 有一条规则，要求将变更的代码拆分为单独的补丁。每个补丁都必须做一件事，且只做一件事，而且每个补丁都应该有自己的描述性提交消息。提交消息比代码变更本身还要长得多的情况早已司空见惯。
透过这个例子，可以发现大多数组织往往忽视了什么。在 GitHub 上，我看到大多数现代项目的提交信息都类似于“8 月 25 日，检查点” ，或者稍微好一点（但也仅仅稍微好一点）的是“实现 X 函数” 。如果别人之后需要查看这些代码，将无法理解为什么要按照当时的方式来完成这个变更。有些缺陷非常微妙，而且很容易重复出现。只看简短的、非描述性的提交消息，不一定有人能知道在什么条件下会出现错误。
举个简单的例子，看看我的好朋友 Johannes Weiner 的 Linux 提交，不难想象，一些其他项目可能只会草草写下“删除警告”之类的。而再看看这段信息，阅读它我能知道为什么删除这些警告很安全（说明了当前情况很安全的原因），以及如果我在未来更改这段代码时应该要做些什么。我相信，很多组织也会有人这么做。但是由于 Linux 过程是强制执行的，所以我百分百确信通过阅读提交消息能理解本次变更的所有相关信息。如果我们讨论的是一个 bug ，我就会知道它出现在哪些系统，发生在什么条件下，为什么没有影响到其他的系统，以及我应该做些什么来避免再次犯同样的错误。