當我接手一個新的程式碼庫時，第一件事通常不是打開程式碼，而是開啟終端機並執行幾個 Git 指令。在看任何檔案之前，提交歷史就能給我一個專案的診斷圖像：誰建立了它、問題集中在哪裡、團隊是自信地持續交付還是小心翼翼地避開地雷。
我會從 app/ 或 src/ 目錄執行這些指令，而不是從倉庫根目錄開始，因為鎖定檔、變更日誌和自動生成的程式碼會佔據列表。
過去一年中變動最多的 20 個檔案。排在最上面的檔案幾乎總是大家警告我的那個。「喔，那個檔案，大家都不敢碰。」
檔案的高變動率不代表它不好，有時只是活躍開發的象徵。但沒有人願意負責且變動頻繁的檔案，是我所知道最明顯的問題訊號。那是每次修改都像是在修補修補的檔案，一點小改動的影響範圍難以預測。團隊會在估算時留出緩衝，因為他們知道它會反撲。
2005 年微軟研究發現，相對變動率（以元件大小標準化的變動）能很好預測缺陷密度，而絕對變動數量本身預測力較差。上述指令是絕對變動數量，因此我會從這份清單取前五名檔案，並與下方的錯誤熱點指令交叉比對。變動率高且錯誤多的檔案，是你最大的風險。Adam Tornhill 的《Your Code as a Crime Scene》建立了一套完整的基於變動分析的方法論，包含這些原始指令無法涵蓋的複雜度疊加分析。
依提交數量排名的每位貢獻者。如果一人佔 60% 以上，那就是你的 "bus factor"（關鍵人風險）。如果他六個月前離開，那就是危機。如果整體短期提交榜的頂尖貢獻者，在過去六個月的提交中沒有出現（git shortlog -sn --no-merges --since="6 months ago"），我會立刻向客戶提出警告。
我也會觀察尾端。三十位貢獻者中，過去一年只有三位活躍。建立系統的人已不再維護它。
一個注意事項是：squash-merge 工作流程會壓縮作者資訊。如果團隊將每個 PR 壓縮成一個提交，這份輸出反映的是合併者而非原作者。判斷前值得先了解合併策略。
與變動指令形狀相同，但過濾出包含錯誤相關關鍵字的提交。將此清單與變動熱點比對，出現於兩者的檔案是最高風險程式碼：它們不斷出錯並持續被修補，卻從未被徹底修復。
這依賴提交訊息的紀律性。如果團隊每次提交都寫「更新東西」，你將得不到任何資訊。但即使是粗略的錯誤密度地圖，也比沒有地圖好。
整個倉庫歷史的每月提交數。我會掃描輸出尋找形態。穩定節奏是健康的。但如果某月提交數突然減半，通常代表有人離開。六到十二個月的下降曲線表示團隊失去動力。週期性高峰後接著安靜的月份，代表團隊將工作批次化釋出，而非持續交付。
我曾向一位 CTO 展示提交速度圖，他說「那是我們第二位資深工程師離職的時間點。」他之前沒將時間軸連結起來。這是團隊資料，不是程式碼資料。
還原與熱修復頻率。一年幾次是正常的。每隔幾週就還原，代表團隊不信任部署流程。這是更深層問題的證據：測試不可靠、缺少預備環境，或部署管線使回滾比應有的更困難。零結果也是訊號；要麼團隊穩定，要麼沒人寫描述性提交訊息。
危機模式很容易辨識，要麼存在，要麼不存在。
這五個指令花幾分鐘就能執行完。它們不會告訴你所有事，但你會知道先讀哪段程式碼，以及該注意什麼。這就是你第一天能有條理地閱讀程式碼庫，與漫無目的閒逛的差別。
這是我完整程式碼庫稽核的第一個小時所做的事。