Các lệnh Git tôi chạy trước khi đọc bất kỳ mã nào

Năm lệnh git giúp bạn biết được codebase đang gặp vấn đề ở đâu trước khi mở dù chỉ một tệp tin. Các điểm nóng thay đổi (churn hotspots), hệ số bus (bus factor), các cụm lỗi (bug clusters) và các mô hình khủng hoảng.

The Git Commands I Run Before Reading Any Code

Điều đầu tiên tôi thường làm khi tiếp nhận một codebase mới không phải là mở code ra xem. Đó là mở terminal và chạy một vài lệnh git. Trước khi nhìn vào một tệp tin nào, lịch sử commit đã cho tôi một bức tranh chẩn đoán về dự án: ai đã xây dựng nó, các vấn đề tập trung ở đâu, liệu team đang tự tin phát hành sản phẩm hay đang phải rón rén bước qua những bãi mìn.

Điều gì thay đổi nhiều nhất

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

20 tệp tin thay đổi nhiều nhất trong năm qua. Tệp tin nằm ở trên cùng hầu như luôn là tệp mà mọi người cảnh báo tôi về nó. “Ồ phải rồi, tệp đó đấy. Ai cũng sợ phải đụng vào nó.”

Tần suất thay đổi cao trên một tệp không có nghĩa là nó tệ. Đôi khi đó chỉ là do sự phát triển tích cực. Nhưng tần suất thay đổi cao trên một tệp mà không ai muốn chịu trách nhiệm chính là dấu hiệu rõ ràng nhất của sự trì trệ trong codebase mà tôi biết. Đó là tệp mà mọi thay đổi đều là vá víu chồng chất. Bán kính ảnh hưởng của một chỉnh sửa nhỏ là không thể đoán trước được. Team phải tăng dự toán thời gian vì họ biết nó sẽ gây ra rắc rối.

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

Ai đã xây dựng hệ thống 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% hoặc hơn, đó chính là hệ số bus (bus factor) của bạn. Nếu họ đã rời đi từ 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 khoảng thời gian 6 tháng (git shortlog -sn --no-merges --since="6 months ago"), tôi sẽ cảnh báo ngay cho khách hàng.

Tôi cũng nhìn vào danh sách cuối. Ba mươi người đóng góp nhưng chỉ 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 duy trì nó hiện tại.

Một lưu ý nhỏ: quy trình squash-merge làm nén thông tin tác giả. Nếu team gộp (squash) mọi PR thành một commit duy nhất, kết quả này phản ánh ai là người merge, không phải ai là người viết. Nên hỏi về chiến lược merge trước khi đưa ra kết luận.

Các lỗi 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 churn, nhưng được lọc cho các commit có từ khóa liên quan đến lỗi. So sánh danh sách này với các điểm nóng churn. Các tệp xuất hiện trong cả hai danh sách chính là những phần code rủi ro nhất: chúng liên tục bị lỗi và liên tục được vá, nhưng không bao giờ được sửa chữa triệt để.

Việc này phụ thuộc vào tính kỷ luật của thông báo commit. Nếu team viết “cập nhật linh tinh” cho mỗi commit, bạn sẽ chẳng thu được gì. Nhưng ngay cả một bản đồ sơ lược về mật độ lỗi cũng tốt hơn là không có gì cả.

Dự án này đang tăng tốc hay đang 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ử repo. Tôi quét kết quả để tìm các hình dạng. Nhịp điệu ổn định là dấu hiệu khỏe mạnh. Nhưng nếu số lượng giảm một nửa trong một tháng thì sao? Thường là do ai đó đã rời đi. Một đường cong đi xuống trong vòng 6 đến 12 tháng cho thấy team đang mất dần động lực. Những đợt tăng đột biến định kỳ theo sau bởi những tháng yên ắng có nghĩa là team gom công việc vào các đợt phát hành thay vì phát hành liên tục.

Tôi từng cho một CTO xem 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ọ đã không kết nối được các mốc thời gian trước đó. Đây là dữ liệu về team, không phải dữ liệu code.

Team thường xuyên phải chữa cháy như thế nào

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

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

Các mô hình khủng hoảng rất dễ đọc. Hoặc là chúng tồn tại, 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 nói cho bạn mọi thứ. Nhưng bạn sẽ biết nên đọc phần code nào trước, và nên tìm kiếm điều gì khi bắt đầu đọc. Đó 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 dành cả ngày để đi lòng vòng.

Đây là giờ đầu tiên trong những gì tôi làm trong một cuộc kiểm toán codebase. Dưới đây là những việc còn lại trong tuần.