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，我就會知道它出現在哪些系統，發生在什么條件下，為什么沒有影響到其他的系統，以及我應該做些什么來避免再次犯同樣的錯誤。

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

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

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

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

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

Backport 還是不 Backport 呢，它有好處，但也伴隨著階梯式的成本。現在程序員不僅要關心代碼，而且還要關心如何重組和調整這些代碼。

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

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

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

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

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

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

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

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

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

2. 有解決辦法嗎？

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

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

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

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

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