中文摘要：Linux從誕生至今，已經快有30年了。這期間Linux一直延續着通過郵件來提交變更、審查、討論直至批准的研發過程，這一流程非常費時費力，不僅成爲新人的進入門檻，也成了可持續生產的障礙。那麼，爲什麼Linux一直要堅持遵循這一過程呢，它能帶來什麼好處？存在哪些弊端？有什麼解決辦法嗎？
正文：
本文最初發佈於medium，經原作者授權由InfoQ中文站翻譯並分享。
Linux從誕生至今，已經快有30年了。在早期，由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卻至關重要。
提交消息和補丁
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放棄這個過程將贏得多少、將失去什麼，僅這一點它就是完美的，有理由繼續貫徹這個一直運轉良好的過程。
有解決辦法嗎？
我由衷地相信，如果我們有工具可以讓一個組織實現Linux過程中同樣的好處，那將是每個人的巨大勝利。面對着這樣的工具，甚至Linux也可能不再使用純文本電子郵件了。
我不知道這樣的工具會是什麼樣的。但也許我可以大膽地設想一下：
- Git是一個源代碼控制系統，本質上源代碼控制系統希望添加歷史，而不是重寫歷史。然而，GitHub中的開發過程卻把兩者混爲一談了，開發和評審以git提交爲準，而純文本Linux開發人員是在他們自己的本地git樹中開發的，不斷在重寫歷史。也許我們需要將其一分爲二，允許在單獨的工具中進行開發和評審，這樣本質上週期會更短暫，代碼更容易得到處理。Git用來存儲結果。一個很好的類比是，CSS允許HTML開發人員將表示層與邏輯層分離。還記得CSS出現之前的HTML嗎？不好，我是不是暴露年齡了……
- 接上述內容繼續擴展，可能逐行描述補丁差異會使每件事情都很難開展。我們是否可以有一個系統，在這個系統中，我們可以在更高的層次上描述我對代碼所做的那些更改，並明確這些變更能夠應用到其他什麼地方？例如，我可以說“將create_bar()函數移到create_foo()之前”或者“在create_bar()參數列表最後添加一個名爲y的整型參數”。即使後續的變更會在代碼環境中添加一些東西，破壞了逐行差異，這樣系統仍然能夠將變更應用到雖被修改但只是版本稍有不同的代碼庫上。也許我太天真了，這是不可能的，但GPT-3取得了一些令人大開眼界的進步，看到這些我覺得可能也並不遙遠。
- 或者如果沒有那麼大的野心，也許有一種中間解決方案，那就是總是對追加的代碼進行代碼審查。如果所有部分都得到了認可，那麼此時此刻，也僅在此時此刻，歷史才被改寫。更簡單、更易用的工具可以幫助維護者確保與已批准的代碼不存在差異，以覈實所做的變更都是圍繞重組進行的。
原文鏈接：The Linux development process: Is it worth the hassle?
譯者簡介：冬雨，小小技術宅一枚，從事研發過程改進及質量改進方面的工作，關注編程、軟件工程、敏捷、DevOps、雲計算等領域，非常樂意將國外新鮮的IT資訊和深度技術文章翻譯分享給大家，已翻譯出版《深入敏捷測試》、《持續交付實戰》。