2005年4月7日,“閉關”一周的Linus上傳了一個不起眼的小工具。
在注釋中,Linus把它稱為“the information manager from hell”。
它就是Git 0.0.1,此時只有不到1000行的C代碼:
這些代碼被編譯成7個單獨的可執行命令:init-db、update-cache、show-diff、write-tree、read-tree、commit-tree、cat-file
現在看看這些命令,你可能會好奇,這是那個名揚天下的Git嗎?
clone命令在哪兒?add命令在哪兒?
在軟件工程中,有個叫做“管道和瓷器”的比喻,管道指的是底層基礎設施,低級的API,通常比較原始,不美觀。
瓷器表示高級功能,友好的界面,例如如洗手池,用戶直接使用它,不用看到管道里復雜的水流。
此時的Git0.0.1就是典型的“管道”,使用起來非常麻煩。
但是Linus在開源界影響力無與倫比,他一發布Git,就立刻引發了熱烈的討論。
尤其是那些想參與開源,想在開源中留名的年輕人,其中一位就是日本人濱野純(Junio Hamano)
0 1
濱野純從東京大學畢業后進入了Twin Sun公司,這家美國外企是個“神仙”公司,竟然采取遠程優先的工作模式。
后來公司在洛杉磯有個小項目,濱野純被派去了美國,在這里他遇到了一位導師Paul Eggert。
Paul是開源領域的著名人物,時間區數據庫(TZDB)維護者,GNU項目的長期貢獻者,在他的影響下,濱野純走上了開源和自由軟件的道路。
就是在這個時候,濱野純看到Linus公布了Git,他立刻就下載了源代碼,不到一千行代碼!花兩個小時就看完了!
這對于那些想參與開源的人,真是一個幸福的時刻。
因為很多開源軟件成名以后,規模非常龐大,想把代碼讀一遍都很難,要參與進去做貢獻非常麻煩,只能從提個issue,fix個Bug開始。
但是Git不同,初始版本就在眼前,1000行代碼,了無秘密,何況還是自己的偶像Linus寫的,設計簡潔,代碼清晰。
此時不加入,更待何時?
當然,事情都有兩面性,越是開源項目的早期,對人的要求就越高。
比如Linus在郵件列表中提了一個需求:用腳本語言實現Merge功能(沒錯,Git0.0.1還沒有實現merge)。
可是幾天過去了,沒人響應。
濱野純出手了,他用Perl寫了一個Merge實現,發到了郵件列表。
Linus看到后很興奮:這正是我想要的..... 于是兩人就在郵件列表中不斷地討論,修改代碼,最終找到了一個優雅的方案來實現Merge。
和自己的偶像一起工作,開發開源軟件,這種感覺肯定是無與倫比的。
濱野純在Twin Sun公司有自己的日常工作,剛開始的時候,他主要在早上上班之前,以及下班之后和周末來進行Git相關的開發,后來他發現自己的辦公室隔間沒人能偷看,在白天也可以“偷摸”著干點兒Git的活兒。
(其實濱野純的公司Twin Sun也很開明,后來NEC一起贊助濱野純用20%的工作時間,兼職開發Git。)
濱野純對Git的貢獻越來越多,他逐漸贏得了Linus和整個社區的信任,僅僅三個月以后,Linus就宣布將Git維護者移交給濱野純。
這個過程看起來一帆風順,似乎只要你用心投入時間開發就可以,實際上并不是這樣的。
當時有很多優秀的程序員在參與開發,不少還是從Linux內核社區過來的。
對同一個功能,可能有多個競爭者同時在設計和開發,濱野純的設計要精良,代碼要漂亮。
開發速度不但要快,還得能很好地給競爭者展示出來,說服別人。
所以,開發的過程就像一場混亂的競爭,濱野純能勝出,關鍵的原因就是Linus所說的:
“有明顯的、非常重要但難以具體描述的‘好品位’”
“這樣的人雖然稀有,但你一眼就能認出來。我覺得自己最大的成功之一,其實發生在 Linux 之外:那就是我找到了濱野純來維護Git項目。”
濱野純也沒有辜負Linus的信任,成為維護者后,一干就是20年,帶領Git成為世界上最流行的版本控制軟件。
那什么是“好品位”呢? 我覺得至少有兩點:
1.能分辨什么是好設計,什么是壞設計
2.懂得取舍和簡潔
比如Git,核心的數據結構只有四種:Blob、Tree、Commit、Tag。
這四者加上哈希引用,居然就能表達整個歷史樹!
設計極度簡潔,但威力無窮。
這和 UNIX 哲學一樣,少而精,組合強大。
0 2
Linus夸濱野純技術品位好,不由得讓我想起另外一位更加知名的日本程序員:松本行弘。
松本行弘是Ruby之父,在設計Ruby的過程中展示了極佳的技術品位。
1. 平衡“靈活”與“可控”
Ruby以動態性和元編程能力著稱,但松本行弘在設計中刻意規避了某些過度自由的特性(如Lisp風格的宏),以避免代碼可讀性崩潰。
他很克制,拒絕完全開放語法,但提供了attr_accessor等元編程工具,這就讓Ruby代碼既靈活,又不會因過度自由而失控。
2. 面向對象的純粹性與實用性
Ruby將Smalltalk的面向對象思想推向極致,同時解決實際痛點:
一切皆對象:包括基本類型(如1.class #=> Integer),實現概念一致性。
Mix-in優于多重繼承:通過module實現功能組合,避免C++多重繼承的復雜性。
3. 函數式特性的優雅融合
Ruby并非函數式語言,但巧妙吸收了高階函數和閉包:
代碼塊(Block):
- 受Lisp啟發,但通過do...end/{}語法更符合命令式語言習慣。
- 實現迭代器(如each)和回調(如File.open的自動資源釋放)。
鏈式數據流:map/select/reduce組合操作時,代碼如自然語言般流暢。
所以使用Ruby編程,給人的感覺特別舒服,代碼非常優雅,后來也隨著Ruby on Rails的東風而大爆。
松本行弘后來曾嘗試設計一種基于流模型的并發編程語言,名為 Streem,旨在將數據流編程的理念引入更廣泛的應用場景,其核心思想是通過管道連接多個任務,實現數據的流動與轉換。
比如這個例子:生成 1 到 100 的序列,每個數乘以 2 后輸出。
seq(100) | map { x -> x * 2 } | stdout還有這個:Streem 自動將任務分配到多線程,無需手動管理:
fread("large_file.txt") | map { line -> process(line) } | fwrite("output.txt")都是把流式編程變得像寫shell腳本一樣簡單。
0 3
濱野純和松本行弘技術品位極佳,但是他們并不能代表日本程序員,我搜了一下,發現起源于日本/日本程序員主導的知名開源軟件并不多,遠遠比不上中國,有知道日本開源軟件詳情的朋友歡迎告知。
不管如何,我們都能看到技術品位的巨大力量,對好設計的追求,對簡潔的追求,會讓軟件具備長久的生命力,而這一點,是人工智能很難做到的。
無論你是程序員,還是未來的軟件架構師,學會欣賞并培養這種“好品位”,才是走向卓越的必經之路。
Git 0.0.1 下載:https://www.kernel.org/pub/software/scm/git/
特別聲明:以上內容(如有圖片或視頻亦包括在內)為自媒體平臺“網易號”用戶上傳并發布,本平臺僅提供信息存儲服務。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.