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

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

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

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

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

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

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

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

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

1. 提交消息和補(bǔ)丁

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

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

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

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

而對(duì)于 Linux 來(lái)說(shuō)，這卻是至關(guān)重要的，原因有兩個(gè)：

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

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

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

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

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

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

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

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

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

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

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

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

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

2. 有解決辦法嗎？

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

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

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

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

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