Linux系統(tǒng)堅持30年不變的研發(fā)過程，存在哪些弊端和好處？

Linux 從誕生至今，已經(jīng)快有 30 年了。這期間 Linux 一直延續(xù)著通過郵件來提交變更、審查、討論直至批準的研發(fā)過程，這一流程非常費時費力，不僅成為新人的進入門檻，也成了可持續(xù)生產(chǎn)的障礙。那么，為什么 Linux 一直要堅持遵循這一過程呢，它能帶來什么好處？存在哪些弊端？有什么解決辦法嗎？

在早期，由 Linus 自己手工管理大家貢獻的代碼，不借助任何版本控制系統(tǒng)。而現(xiàn)在，已經(jīng)使用 git 了。

然而，有一件事在整個過程中卻從來都沒有變過：代碼被發(fā)送到一個（或多個）郵件列表中，然后直到做出最終判定之前，要進行一系列的審查和討論。

盡管 Linux 是成功的，但這一過程卻一直飽受詬病。微軟的 Sarah Novotny 最近在社交媒體上發(fā)表了一篇文章，稱 Linux 所使用的協(xié)作工具早已過時，如果這個社區(qū)想要吸引新鮮血液，最好換掉這些工具。

我認為我對此有一定的發(fā)言權(quán)：近十年來，我就在用類似的工作流程為 Linux 和其他項目編寫代碼。就職于 Red Hat 的時候，我為 core x86 基礎(chǔ)設(shè)施、KVM 管理程序和 QEMU、Xen 管理程序和其他系統(tǒng)貢獻過代碼。雖然，我因為把主要精力投入到了 Seastar C++ 框架和 ScyllaDB 數(shù)據(jù)庫上，在大約 7 年的時間里沒有過多接觸過 Linux，但它們采用的開放方式卻與 Linux 非常相似?，F(xiàn)在我是一名 Datadog 公司的工程師，該公司遵循的流程與其他網(wǎng)絡(luò)公司幾乎完全不同。

那么我的立場是什么呢？首先，我的態(tài)度很明確：我不喜歡 Linux 的開發(fā)過程。我堅信，這一過程不僅是進入的門檻，是可持續(xù)生產(chǎn)的障礙（盡管并不是因為電子郵件），也是令人產(chǎn)生沮喪情緒的源頭。我不打算在任何項目中遵循這一流程，如果我能決定這些項目怎么做的話。

但與此同時，似乎許多對 Linux 過程持批評態(tài)度的人認為，它的捍衛(wèi)者之所以如此頑固地墨守成規(guī)，只是因為 Linux 充斥著一些不愿做出改變的堅守者。盡管我相信的確存在這樣一些個別人，但事實上真正的原因并非如此。Linux 所遵循的開發(fā)過程提供了一些獨一無二的重要優(yōu)勢，這些優(yōu)勢對于任何其他組織也均有裨益。

除電子郵件以外，任何其他自以為是的工具化都會迫使 Linux 拋棄這些好處，大家不愿意舍棄的是這些好處，而不是電子郵件。工具化應(yīng)可以降低進入的門檻，改正過程中那些令人沮喪的方面，同時能夠讓組織實現(xiàn) Linux 所具備的真正推進軟件開發(fā)的好處。

這樣的優(yōu)勢有很多，但是由于時間的關(guān)系，我會著重來談其中我認為最重要的那一個。我將盡最大努力向你解釋它是什么，為什么盡管它有優(yōu)點卻又如此令人沮喪，為什么它只是對其他組織有益，但對 Linux 卻至關(guān)重要。

1. 提交消息和補丁

Linux 有一條規(guī)則，要求將變更的代碼拆分為單獨的補丁。每個補丁都必須做一件事，且只做一件事，而且每個補丁都應(yīng)該有自己的描述性提交消息。提交消息比代碼變更本身還要長得多的情況早已司空見慣。

透過這個例子，可以發(fā)現(xiàn)大多數(shù)組織往往忽視了什么。在 GitHub 上，我看到大多數(shù)現(xiàn)代項目的提交信息都類似于“8 月 25 日，檢查點”，或者稍微好一點（但也僅僅稍微好一點）的是“實現(xiàn) X 函數(shù)”。如果別人之后需要查看這些代碼，將無法理解為什么要按照當時的方式來完成這個變更。有些缺陷非常微妙，而且很容易重復(fù)出現(xiàn)。只看簡短的、非描述性的提交消息，不一定有人能知道在什么條件下會出現(xiàn)錯誤。

舉個簡單的例子，看看我的好朋友 Johannes Weiner 的 Linux 提交，不難想象，一些其他項目可能只會草草寫下“刪除警告”之類的。而再看看這段信息，閱讀它我能知道為什么刪除這些警告很安全（說明了當前情況很安全的原因），以及如果我在未來更改這段代碼時應(yīng)該要做些什么。我相信，很多組織也會有人這么做。但是由于 Linux 過程是強制執(zhí)行的，所以我百分百確信通過閱讀提交消息能理解本次變更的所有相關(guān)信息。如果我們討論的是一個 bug，我就會知道它出現(xiàn)在哪些系統(tǒng)，發(fā)生在什么條件下，為什么沒有影響到其他的系統(tǒng)，以及我應(yīng)該做些什么來避免再次犯同樣的錯誤。

無論對于哪個組織，這都是值得的：它能使別人（包括將來的你）更容易理解為什么要做這個變更，為什么代碼以這種方式運轉(zhuǎn)，這可以使新人更快速地成長，可以防止重復(fù)出現(xiàn)相同的 Bug，減少因偷偷挾帶無關(guān)的代碼而造成破壞的風險。

而對于 Linux 來說，這卻是至關(guān)重要的，原因有兩個：

很多人有著不同的背景、來自于不同的公司，這些公司有著不同的動機和議程。公司內(nèi)部的大型項目可以使用其他機制來傳遞信息和確保職責。很少有開源項目能像 Linux 那樣龐大、長壽，受著這么多人的影響。

Backport：鑒于其規(guī)模和重要性，分支一直是 Linux 的常態(tài)。即使是現(xiàn)在（2020 年），一些發(fā)行版也可能是在它們視為 LTS 的版本上加上自己的補丁。即使現(xiàn)在這種情況相比 2000 年初有所下降，也只是因為 Linux 本身開始有了自己的 LTS 系列，發(fā)行版可以以這些版本為基礎(chǔ)了。

許多現(xiàn)代線上公司不需要保持產(chǎn)品線的兼容性，通常不存在 Backport 的問題。他們只關(guān)心交付即可。但是如果涉及到 Backport，事情就變得比較復(fù)雜了。開發(fā)人員（很可能不是作者）可能必須要選擇如何對代碼進行微調(diào)，以適應(yīng)略有不同的、較舊的代碼庫。若要將風險降至最低，可以只 Backport 大變更的某些部分，大家通常都這么做。假設(shè)，一個 2，000 行的代碼變更中有 5 行修復(fù)了一個 bug。再設(shè)，該 bug 的修復(fù)可能是在 API 重構(gòu)之后。你是愿意基于一個大變更來做 Backport 呢，還是愿意基于一個文檔非常完善、描述得很充分、做過合理拆分的補丁來做 Backport 呢？作為一個做過無數(shù)次 Backport 的人，我很清楚我的選擇是什么。

Backport 還是不 Backport 呢，它有好處，但也伴隨著階梯式的成本?，F(xiàn)在程序員不僅要關(guān)心代碼，而且還要關(guān)心如何重組和調(diào)整這些代碼。

其中有一些重組很容易：你可以使用 git add -p 選擇哪些部分可以添加到每個變更中。當開始發(fā)現(xiàn)代碼片段之間出現(xiàn)循環(huán)依賴時，就變得有點復(fù)雜了。假設(shè)有一個函數(shù)，它返回的對象類型是以后才引入的。那么你不得不添加一些代碼處理這一情況，這些代碼最終并不會出現(xiàn)在這個項目中，它們只是作為臨時粘合劑。

這一切的一切都很令人沮喪，但卻也不是不可避免。假設(shè)，你將所有工作都進行了完美分解，使其很容易得以處理。當人們進行代碼審查時，就開始出現(xiàn)真正的問題了。任何組織做代碼審查都大同小異。大家閱讀代碼并提出修改建議 （或要求）。

假設(shè)，評審意見是我在第一次變更中添加的方法應(yīng)該有一個額外的參數(shù)。再假設(shè)，我在以后的所有補丁中都使用了這個方法。

現(xiàn)在我不得不回到第一個補丁添加參數(shù)，于是，所有后續(xù)的補丁都無法正常使用了?，F(xiàn)在我不僅要開動腦筋找出原因，還要手動修正所有的錯誤。如果我以前已經(jīng)測試過某個補丁了，那么現(xiàn)在那個測試已經(jīng)無效了，我必須重新測試。

重組只是一個小問題。但為現(xiàn)有工作重新建立基線是一個真正的大問題。

我希望 Linux 社區(qū)和朋友們能夠理解：顯然，這么做并不是不行。但如果這都不算是進入的門檻，我就不知道什么才是了。大家不得不花費時間、精力、腦力和計算機來重組、重寫、返工，沒有人想做這些事情。我還發(fā)現(xiàn)有時大家會爭論：“……但對于優(yōu)秀的程序員來說會沒有問題的”或者“但是它迫使你以這種或那種方式思考，優(yōu)秀的程序員應(yīng)該這么思考”，這種觀點脫離實際毫無用處：上帝，我剛才已經(jīng)承認了這個方法的所有好處，并且發(fā)現(xiàn)重組這些代碼絕對是對靈魂的摧殘和折磨。我們以打掃家庭衛(wèi)生為例：一個人可以隨時宣揚保持房間清潔的好處（我完全同意），并且完全有能力用吸塵器打掃房間（我也完全同意），但通常我不會這樣做。原因很簡單，我還有其他我認為更重要的事情要做。這就是為什么我對我的 Roomba 很滿意，它讓我實現(xiàn)了保持房間清潔的所有好處，但又不必我親自動手。這引出了我下面的觀點……

但是我也希望 Linux 圈外的人能夠理解：Linux 所遵循的過程有著切實的優(yōu)勢。沒有一種工具能完全勝任這項任務(wù)。以 GitHub 為例，它的工作流程非常好，原則上總是基于現(xiàn)有代碼添加新的代碼。但它可以強行 push 分支，使 commit 上的評論變得毫無意義，使討論變得毫無意義。

現(xiàn)代開發(fā)工具使許多事情變得更容易：你可以觸發(fā)動作、集成 CI/CD 流水線、給變更的相關(guān)人員發(fā)通知等等。但在客觀上，它們使得我們更難拆分工作了。純文本的電子郵件使許多事情變得更麻煩，但它也并不會妨礙施行能得到理想結(jié)果的過程。

即使可以客觀、準確地說出 Linux 放棄這個過程將贏得多少、將失去什么，僅這一點它就是完美的，有理由繼續(xù)貫徹這個一直運轉(zhuǎn)良好的過程。

2. 有解決辦法嗎？

我由衷地相信，如果我們有工具可以讓一個組織實現(xiàn) Linux 過程中同樣的好處，那將是每個人的巨大勝利。面對著這樣的工具，甚至 Linux 也可能不再使用純文本電子郵件了。

我不知道這樣的工具會是什么樣的。但也許我可以大膽地設(shè)想一下：

Git 是一個源代碼控制系統(tǒng)，本質(zhì)上源代碼控制系統(tǒng)希望添加歷史，而不是重寫歷史。然而，GitHub 中的開發(fā)過程卻把兩者混為一談了，開發(fā)和評審以 git 提交為準，而純文本 Linux 開發(fā)人員是在他們自己的本地 git 樹中開發(fā)的，不斷在重寫歷史。也許我們需要將其一分為二，允許在單獨的工具中進行開發(fā)和評審，這樣本質(zhì)上周期會更短暫，代碼更容易得到處理。Git 用來存儲結(jié)果。一個很好的類比是，CSS 允許 HTML 開發(fā)人員將表示層與邏輯層分離。還記得 CSS 出現(xiàn)之前的 HTML 嗎？不好，我是不是暴露年齡了……

接上述內(nèi)容繼續(xù)擴展，可能逐行描述補丁差異會使每件事情都很難開展。我們是否可以有一個系統(tǒng)，在這個系統(tǒng)中，我們可以在更高的層次上描述我對代碼所做的那些更改，并明確這些變更能夠應(yīng)用到其他什么地方？例如，我可以說“將 create_bar（） 函數(shù)移到 create_foo（） 之前”或者“在 create_bar（） 參數(shù)列表最后添加一個名為 y 的整型參數(shù)”。即使后續(xù)的變更會在代碼環(huán)境中添加一些東西，破壞了逐行差異，這樣系統(tǒng)仍然能夠?qū)⒆兏鼞?yīng)用到雖被修改但只是版本稍有不同的代碼庫上。也許我太天真了，這是不可能的，但 GPT-3 取得了一些令人大開眼界的進步，看到這些我覺得可能也并不遙遠。

或者如果沒有那么大的野心，也許有一種中間解決方案，那就是總是對追加的代碼進行代碼審查。如果所有部分都得到了認可，那么此時此刻，也僅在此時此刻，歷史才被改寫。更簡單、更易用的工具可以幫助維護者確保與已批準的代碼不存在差異，以核實所做的變更都是圍繞重組進行的。
責編AJX