Những lệnh Git tôi luôn chạy trước khi đọc bất kỳ đoạn code nào

Khi tiếp cận một kho chứa code (codebase) mới, điều đầu tiên tôi thường làm không phải là mở code lên ngay lập tức. Thay vào đó, tôi mở terminal và chạy một vài lệnh Git. Trước khi nhìn vào bất kỳ tệp tin nào, lịch sử commit đã cung cấp một bức tranh chẩn đoán về dự án: ai xây dựng nó, vấn đề thường tập trung ở đâu, và liệu đội ngũ đang tự tin triển khai hay đang đi bộ quanh mìn.

Git Commands

Những tệp thay đổi nhiều nhất

git log --format=format: --name-only --since="1 year ago" | sort | uniq -c | sort -nr | head -20

Lệnh này liệt kê 20 tệp được thay đổi nhiều nhất trong năm qua. Tệp đứng đầu danh sách hầu như luôn là tệp mà mọi người cảnh báo nhau: "À, cái tệp đó. Ai cũng sợ đụng vào nó."

Tần suất thay đổi cao (high churn) không nhất thiết là xấu, đôi khi nó chỉ là sự phát triển tích cực. Tuy nhiên, nếu một tệp thay đổi liên tục mà không ai muốn chịu trách nhiệm sở hữu, đó là dấu hiệu rõ ràng nhất của sự trì trệ trong codebase. Đó là nơi mọi thay đổi chỉ là vá lỗi chồng lên vá lỗi. Phạm vi ảnh hưởng của một chỉnh sửa nhỏ là không thể đoán trước. Đội ngũ phải ước tính thời gian cao hơn vì họ biết code sẽ "đánh trả".

Một nghiên cứu của Microsoft Research năm 2005 đã chỉ ra rằng các chỉ số dựa trên tần suất thay đổi dự đoán lỗi đáng tin cậy hơn các chỉ số độ phức tạp đơn thuần. Tôi thường lấy 5 tệp đầu tiên từ danh sách này và đối chiếu chúng với lệnh tìm điểm nóng lỗi bên dưới. Một tệp có tần suất thay đổi cao và nhiều lỗi là rủi ro lớn nhất của bạn.

Ai là người xây dựng dự án này

git shortlog -sn --no-merges

Mỗi người đóng góp được xếp hạng theo số lượng commit. Nếu một người chiếm 60% trở lên, đó là "bus factor" (nguy cơ nếu người đó nghỉ việc hoặc gặp sự cố). Nếu người đó đã rời đi sáu tháng trước, đó là một cuộc khủng hoảng. Nếu người đóng góp hàng đầu từ danh sách tổng thể không xuất hiện trong cửa sổ 6 tháng (thêm --since="6 months ago"), tôi sẽ báo ngay cho khách hàng.

Tôi cũng xem xét phần đuôi của danh sách. Ba mươi người đóng góp nhưng chỉ có ba người hoạt động trong năm qua. Những người xây dựng hệ thống này không phải là những người bảo trì nó.

Một lưu ý nhỏ: quy trình squash-merge sẽ nén thông tin tác giả. Nếu đội ngũ squash mọi PR thành một commit duy nhất, kết quả đầu ra sẽ phản ánh người thực hiện merge chứ không phải người viết code. Nên hỏi về chiến lược merge trước khi rút kết luận.

Các lỗi thường tập trung ở đâu

git log -i -E --grep="fix|bug|broken" --name-only --format='' | sort | uniq -c | sort -nr | head -20

Cấu trúc tương tự như lệnh kiểm tra tần suất thay đổi, nhưng được lọc để chỉ bao gồm các commit có từ khóa liên quan đến lỗi. Hãy so sánh danh sách này với các điểm nóng về tần suất thay đổi. Những tệp xuất hiện ở cả hai danh sách là code rủi ro cao nhất: chúng liên tục bị hỏng và được vá, nhưng chưa bao giờ được sửa chữa triệt để.

Điều này phụ thuộc vào kỷ luật viết thông điệp commit. Nếu đội ngũ viết "update stuff" cho mọi commit, bạn sẽ không nhận được gì. Nhưng ngay cả một bản đồ thô sơ về mật độ lỗi cũng tốt hơn là không có gì.

Dự án đang tăng tốc hay "chết dần"?

git log --format='%ad' --date=format:'%Y-%m' | sort | uniq -c

Số lượng commit theo tháng cho toàn bộ lịch sử của kho chứa. Tôi quét kết quả đầu ra để tìm các hình dạng. Một nhịp điệu ổn định là lành mạnh. Nhưng nó trông như thế nào khi số lượng giảm một nửa trong một tháng? Thường là có người đã nghỉ việc. Đường đi xuống trong 6 đến 12 tháng cho thấy đội ngũ đang mất đà. Các đỉnh nhọn định kỳ xen kẽ những tháng yên tĩnh có nghĩa là đội ngũ gom công việc thành các bản phát hành (release) thay vì ship liên tục.

Tôi từng chỉ cho một CTO biểu đồ tốc độ commit của họ và họ nói: "Đó là lúc chúng tôi mất kỹ sư cấp cao thứ hai." Họ chưa bao giờ kết nối dòng thời gian này trước đó. Đây là dữ liệu về đội ngũ, không phải dữ liệu về code.

Đội ngũ "chữa cháy" thường xuyên như thế nào?

git log --oneline --since="1 year ago" | grep -iE 'revert|hotfix|emergency|rollback'

Tần suất các lệnh revert và hotfix. Một vài lần trong một năm là bình thường. Revert mỗi vài tuần có nghĩa là đội ngũ không tin tưởng quy trình triển khai của họ. Chúng là bằng chứng của một vấn đề sâu hơn: test không đáng tin cậy, thiếu môi trường staging, hoặc pipeline triển khai khiến việc rollback khó khăn hơn mức cần thiết. Không có kết quả nào cũng là một tín hiệu; hoặc đội ngũ rất ổn định, hoặc không ai viết thông điệp commit mô tả.

Các mô hình khủng hoảng rất dễ đọc. Hoặc là chúng ở đó, hoặc là không.

Năm lệnh này chỉ mất vài phút để chạy. Chúng sẽ không cho bạn biết mọi thứ. Nhưng bạn sẽ biết nên đọc code nào trước và tìm kiếm điều gì khi đến đó. Đó là sự khác biệt giữa việc dành ngày đầu tiên để đọc codebase một cách có phương pháp và việc lang thang không mục đích.