機(jī)器之心編輯部

問(wèn)大家一個(gè)問(wèn)題：當(dāng)你接觸一個(gè)陌生的代碼庫(kù)時(shí)，第一步是做什么？

相信大多數(shù)人的做法是，打開 README，從目錄開始，一行一行往下讀。但現(xiàn)在，一些工程師開始采用一種完全不同的方法：在看代碼之前，先看 Git。

最近，一篇名為「在閱讀任何代碼之前，我會(huì)運(yùn)行的 Git 命令」的文章引發(fā)網(wǎng)友熱議，文中提出一個(gè)看似簡(jiǎn)單卻頗具顛覆性的觀點(diǎn)：代碼只是結(jié)果，Git 才是過(guò)程。

如何理解？

作者 Ally Piechowski 認(rèn)為，對(duì)于一個(gè)新的代碼庫(kù)，打開終端，運(yùn)行一組 Git 命令，在查看任何文件之前，「提交歷史」就能給出一幅關(guān)于這個(gè)項(xiàng)目的「診斷圖」：是誰(shuí)構(gòu)建了它、問(wèn)題集中在哪些地方、團(tuán)隊(duì)是自信滿滿地交付，還是在雷區(qū)邊緣小心試探……

因此，Ally Piechowski 建議，在讀代碼之前，可以先運(yùn)行這五個(gè) Git 命令：

一、哪些地方改動(dòng)最多

通過(guò)這一 Git 命令，可以查看過(guò)去一年中改動(dòng)最多的 20 個(gè)文件，排在最前面的那個(gè)文件，幾乎總是別人會(huì)提前提醒那一個(gè)：「哦對(duì)，就是那個(gè)文件，沒(méi)人敢動(dòng)它?！?/p>

當(dāng)然，高頻改動(dòng)并不一定意味著代碼不好，有時(shí)只是開發(fā)活躍，但如果一個(gè)文件改動(dòng)頻繁，同時(shí)又沒(méi)人愿意接手，那可能就是最明確的「代碼拖累」信號(hào)。這里的每一次修改，往往都是「舊補(bǔ)丁上再打補(bǔ)丁」。一個(gè)小改動(dòng)的影響范圍難以預(yù)測(cè)。團(tuán)隊(duì)在做估算時(shí)會(huì)刻意加 buffer，因?yàn)樗麄冎肋@塊代碼「會(huì)反抗」。

2005 年微軟研究院的一項(xiàng)研究發(fā)現(xiàn)，基于「變更頻率」（churn）的指標(biāo)，比單純的復(fù)雜度指標(biāo)更能預(yù)測(cè)缺陷。往往一個(gè)同時(shí)「高 churn + 高 bug」的文件，就是最大的風(fēng)險(xiǎn)點(diǎn)。

二、誰(shuí)在寫這些代碼？

查看按提交數(shù)量排序的所有貢獻(xiàn)者，如果一個(gè)人貢獻(xiàn)了 60% 以上，那就可能是「關(guān)鍵人依賴」（bus factor），而如果這個(gè)人已經(jīng)在六個(gè)月前離開了，那就是危機(jī)。

另外在尾部，比如有 30 個(gè)貢獻(xiàn)者，但過(guò)去一年只有 3 個(gè)活躍。這說(shuō)明，構(gòu)建這個(gè)系統(tǒng)的人，并不是現(xiàn)在在維護(hù)它的人。

還需要注意的是：如果團(tuán)隊(duì)使用 squash merge（壓縮合并），作者信息會(huì)被壓縮。這種情況下，結(jié)果反映的是「誰(shuí)合并了代碼」，而不是「誰(shuí)寫了代碼」。因此在下結(jié)論前，最好先了解團(tuán)隊(duì)的合并策略。

三、Bug 都集中在哪？

這一命令的結(jié)構(gòu)與 churn 分析類似，但只篩選包含 Bug 關(guān)鍵詞的提交。將這個(gè)列表與前面的 churn 熱點(diǎn)做對(duì)比，兩個(gè)列表都出現(xiàn)的文件，就是最高風(fēng)險(xiǎn)代碼：它們不斷出問(wèn)題、不斷被修補(bǔ)，但從未被徹底解決。

但同時(shí)，這也依賴于提交信息的規(guī)范程度，如果團(tuán)隊(duì)每次都寫「update stuff」，那幾乎得不到有效信息。不過(guò)即便是粗略的 Bug 分布圖，也比完全沒(méi)有要強(qiáng)。

四、項(xiàng)目是在加速，還是在停滯？

這一命令可以查看整個(gè)倉(cāng)庫(kù)歷史中，每個(gè)月的提交數(shù)量。如果節(jié)奏穩(wěn)定，則說(shuō)明項(xiàng)目是健康的；如果某個(gè)月提交量突然減半，通常意味著有人離開了；如果 6 到 12 個(gè)月呈下降趨勢(shì)，說(shuō)明團(tuán)隊(duì)正在失去動(dòng)能；如果是周期性高峰 + 低谷，說(shuō)明團(tuán)隊(duì)是「集中發(fā)版」，而不是持續(xù)交付。

五、團(tuán)隊(duì)有多頻繁在「救火」？

這一命令是查看「回滾」（revert）與「熱修復(fù)」（hotfix）的頻率。一年內(nèi)偶爾幾次是正常的，但如果每隔幾周就有一次「回滾」，說(shuō)明團(tuán)隊(duì)并不信任自己的發(fā)布流程，而這通常意味著更深層的問(wèn)題：測(cè)試不可靠、缺乏預(yù)發(fā)布環(huán)境（staging），或者部署流程讓「回滾」變得困難。

如果結(jié)果為零，也是一種信號(hào)：要么系統(tǒng)非常穩(wěn)定，要么團(tuán)隊(duì)根本不寫清晰的提交信息。

危機(jī)模式是很容易識(shí)別的：要么存在，要么不存在。

在文章的最后，作者表示，這五個(gè) Git 命令只需要幾分鐘時(shí)間，但卻能讓你知道：應(yīng)該先讀哪些代碼，以及閱讀時(shí)要重點(diǎn)關(guān)注什么，從而讓你在一開始就有策略地理解代碼庫(kù)，而非在其中盲目游走。

其實(shí)，從作者的分享來(lái)看，這幾個(gè) Git 命令，改變了傳統(tǒng)對(duì)代碼庫(kù)的理解方式，提供了一種新的視角，看到的不再只是「現(xiàn)在的代碼長(zhǎng)什么樣」，而是「現(xiàn)在的代碼為何會(huì)變成這樣」。

與此同時(shí)，這種新穎的視角在 Hacker News 上并沒(méi)有被完全接受，大家熱議：這，真的靠譜嗎？

有網(wǎng)友認(rèn)為，Git 數(shù)據(jù)并不總是可靠，Commit Message 也會(huì)很水。

他表示，「如果團(tuán)隊(duì)有規(guī)范的提交信息，這些方法才有用?！沟F(xiàn)實(shí)中，無(wú)論大公司還是中小企業(yè)，提交記錄往往混亂，清一色的「Changes」、隨意 merge、莫名 revert，還有一些人，明明團(tuán)隊(duì)約定用 rebase，卻還是會(huì)提交 merge commit。

所以，他認(rèn)為，「這一套方法主要只在中大型開源項(xiàng)目中才真正有用 —— 那些有清晰的 CONTRIBUTING.md/ README.md，以及明確的提交規(guī)范和合并流程的項(xiàng)目?！?/p>

還有網(wǎng)友認(rèn)為，這種方法是在過(guò)度解讀 Git 數(shù)據(jù)，Git 分析并不總是等于真相，很容易誤導(dǎo)判斷。

他結(jié)合自己的親身經(jīng)歷分析，有時(shí)候開發(fā)者提交次數(shù)多，也許只是因?yàn)樗麄儽旧砟芰Σ恍?。?dāng)然，他也表示，這并不是說(shuō)提交次數(shù)多就等于開發(fā)者不好。只是想提醒大家，如果把這些 Git 命令的結(jié)果當(dāng)成事實(shí)本身，就有可能看不到全貌。

「如果有人跑完這些命令后跑來(lái)跟我說(shuō)：「我發(fā)現(xiàn)某某是提交最多的人，但他 X 個(gè)月前離職了，我們?cè)撛趺崔k？？？」我可能要很努力才能忍住不笑……」

此外，還有一個(gè)爭(zhēng)議點(diǎn)在于，高 churn 是否等于高風(fēng)險(xiǎn)？

網(wǎng)友認(rèn)為，在測(cè)試中接觸最多的文件往往也是最無(wú)關(guān)緊要的文件，比如依賴文件（package.json）、lock file、CI 配置，以及一些自動(dòng)生成文件等，這些文件會(huì)頻繁改動(dòng)，但并不代表復(fù)雜。

因此，更準(zhǔn)確的做法是，將 churn 結(jié)合復(fù)雜度來(lái)看。

那么你呢，你是如何看代碼庫(kù)的？或者覺(jué)得這種方法是否有啟發(fā)，歡迎大家評(píng)論區(qū)留言、交流！

https://piechowski.io/post/git-commands-before-reading-code/

https://news.ycombinator.com/item?id=47687273