2005年4月7日，“閉關(guān)”一周的Linus上傳了一個不起眼的小工具。

在注釋中，Linus把它稱為“the information manager from hell”。

它就是Git 0.0.1，此時只有不到1000行的C代碼：

這些代碼被編譯成7個單獨的可執(zhí)行命令：init-db、update-cache、show-diff、write-tree、read-tree、commit-tree、cat-file

現(xiàn)在看看這些命令，你可能會好奇，這是那個名揚天下的Git嗎？

clone命令在哪兒？add命令在哪兒？

在軟件工程中，有個叫做“管道和瓷器”的比喻，管道指的是底層基礎(chǔ)設(shè)施，低級的API，通常比較原始，不美觀。

瓷器表示高級功能，友好的界面，例如如洗手池，用戶直接使用它，不用看到管道里復(fù)雜的水流。

此時的Git0.0.1就是典型的“管道”，使用起來非常麻煩。

但是Linus在開源界影響力無與倫比，他一發(fā)布Git，就立刻引發(fā)了熱烈的討論。

尤其是那些想?yún)⑴c開源，想在開源中留名的年輕人，其中一位就是日本人濱野純（Junio Hamano）

0 1

濱野純從東京大學(xué)畢業(yè)后進入了Twin Sun公司，這家美國外企是個“神仙”公司，竟然采取遠(yuǎn)程優(yōu)先的工作模式。

后來公司在洛杉磯有個小項目，濱野純被派去了美國，在這里他遇到了一位導(dǎo)師Paul Eggert。

Paul是開源領(lǐng)域的著名人物，時間區(qū)數(shù)據(jù)庫（TZDB）維護者，GNU項目的長期貢獻(xiàn)者，在他的影響下，濱野純走上了開源和自由軟件的道路。

就是在這個時候，濱野純看到Linus公布了Git，他立刻就下載了源代碼，不到一千行代碼！花兩個小時就看完了！

這對于那些想?yún)⑴c開源的人，真是一個幸福的時刻。

因為很多開源軟件成名以后，規(guī)模非常龐大，想把代碼讀一遍都很難，要參與進去做貢獻(xiàn)非常麻煩，只能從提個issue，fix個Bug開始。

但是Git不同，初始版本就在眼前，1000行代碼，了無秘密，何況還是自己的偶像Linus寫的，設(shè)計簡潔，代碼清晰。

此時不加入，更待何時？

當(dāng)然，事情都有兩面性，越是開源項目的早期，對人的要求就越高。

比如Linus在郵件列表中提了一個需求：用腳本語言實現(xiàn)Merge功能（沒錯，Git0.0.1還沒有實現(xiàn)merge）。

可是幾天過去了，沒人響應(yīng)。

濱野純出手了，他用Perl寫了一個Merge實現(xiàn)，發(fā)到了郵件列表。

Linus看到后很興奮：這正是我想要的..... 于是兩人就在郵件列表中不斷地討論，修改代碼，最終找到了一個優(yōu)雅的方案來實現(xiàn)Merge。

和自己的偶像一起工作，開發(fā)開源軟件，這種感覺肯定是無與倫比的。

濱野純在Twin Sun公司有自己的日常工作，剛開始的時候，他主要在早上上班之前，以及下班之后和周末來進行Git相關(guān)的開發(fā)，后來他發(fā)現(xiàn)自己的辦公室隔間沒人能偷看，在白天也可以“偷摸”著干點兒Git的活兒。

（其實濱野純的公司Twin Sun也很開明，后來NEC一起贊助濱野純用20%的工作時間，兼職開發(fā)Git。）

濱野純對Git的貢獻(xiàn)越來越多，他逐漸贏得了Linus和整個社區(qū)的信任，僅僅三個月以后，Linus就宣布將Git維護者移交給濱野純。

這個過程看起來一帆風(fēng)順，似乎只要你用心投入時間開發(fā)就可以，實際上并不是這樣的。

當(dāng)時有很多優(yōu)秀的程序員在參與開發(fā)，不少還是從Linux內(nèi)核社區(qū)過來的。

對同一個功能，可能有多個競爭者同時在設(shè)計和開發(fā)，濱野純的設(shè)計要精良，代碼要漂亮。

開發(fā)速度不但要快，還得能很好地給競爭者展示出來，說服別人。

所以，開發(fā)的過程就像一場混亂的競爭，濱野純能勝出，關(guān)鍵的原因就是Linus所說的：

“有明顯的、非常重要但難以具體描述的‘好品位’”

“這樣的人雖然稀有，但你一眼就能認(rèn)出來。我覺得自己最大的成功之一，其實發(fā)生在 Linux 之外：那就是我找到了濱野純來維護Git項目。”

濱野純也沒有辜負(fù)Linus的信任，成為維護者后，一干就是20年，帶領(lǐng)Git成為世界上最流行的版本控制軟件。

那什么是“好品位”呢？ 我覺得至少有兩點：

1.能分辨什么是好設(shè)計，什么是壞設(shè)計

2.懂得取舍和簡潔

比如Git，核心的數(shù)據(jù)結(jié)構(gòu)只有四種：Blob、Tree、Commit、Tag。

這四者加上哈希引用，居然就能表達(dá)整個歷史樹！

設(shè)計極度簡潔，但威力無窮。

這和 UNIX 哲學(xué)一樣，少而精，組合強大。

0 2

Linus夸濱野純技術(shù)品位好，不由得讓我想起另外一位更加知名的日本程序員：松本行弘。

松本行弘是Ruby之父，在設(shè)計Ruby的過程中展示了極佳的技術(shù)品位。

1. 平衡“靈活”與“可控”

Ruby以動態(tài)性和元編程能力著稱，但松本行弘在設(shè)計中刻意規(guī)避了某些過度自由的特性（如Lisp風(fēng)格的宏），以避免代碼可讀性崩潰。

他很克制，拒絕完全開放語法，但提供了attr_accessor等元編程工具，這就讓Ruby代碼既靈活，又不會因過度自由而失控。

2. 面向?qū)ο蟮募兇庑耘c實用性

Ruby將Smalltalk的面向?qū)ο笏枷胪葡驑O致，同時解決實際痛點：

一切皆對象：包括基本類型（如1.class #=> Integer），實現(xiàn)概念一致性。

Mix-in優(yōu)于多重繼承：通過module實現(xiàn)功能組合，避免C++多重繼承的復(fù)雜性。

3. 函數(shù)式特性的優(yōu)雅融合

Ruby并非函數(shù)式語言，但巧妙吸收了高階函數(shù)和閉包：

代碼塊（Block）：

- 受Lisp啟發(fā)，但通過do...end/{}語法更符合命令式語言習(xí)慣。

- 實現(xiàn)迭代器（如each）和回調(diào)（如File.open的自動資源釋放）。

鏈?zhǔn)綌?shù)據(jù)流：map/select/reduce組合操作時，代碼如自然語言般流暢。

所以使用Ruby編程，給人的感覺特別舒服，代碼非常優(yōu)雅，后來也隨著Ruby on Rails的東風(fēng)而大爆。

松本行弘后來曾嘗試設(shè)計一種基于流模型的并發(fā)編程語言，名為 Streem，旨在將數(shù)據(jù)流編程的理念引入更廣泛的應(yīng)用場景，其核心思想是通過管道連接多個任務(wù)，實現(xiàn)數(shù)據(jù)的流動與轉(zhuǎn)換。

比如這個例子：生成 1 到 100 的序列，每個數(shù)乘以 2 后輸出。

seq(100) | map { x -> x * 2 } | stdout

還有這個：Streem 自動將任務(wù)分配到多線程，無需手動管理：

fread("large_file.txt") | map { line -> process(line) } | fwrite("output.txt")

都是把流式編程變得像寫shell腳本一樣簡單。

0 3

濱野純和松本行弘技術(shù)品位極佳，但是他們并不能代表日本程序員，我搜了一下，發(fā)現(xiàn)起源于日本/日本程序員主導(dǎo)的知名開源軟件并不多，遠(yuǎn)遠(yuǎn)比不上中國，有知道日本開源軟件詳情的朋友歡迎告知。

不管如何，我們都能看到技術(shù)品位的巨大力量，對好設(shè)計的追求，對簡潔的追求，會讓軟件具備長久的生命力，而這一點，是人工智能很難做到的。

無論你是程序員，還是未來的軟件架構(gòu)師，學(xué)會欣賞并培養(yǎng)這種“好品位”，才是走向卓越的必經(jīng)之路。

Git 0.0.1 下載：https://www.kernel.org/pub/software/scm/git/