Một số lập trình viên thích review mã bằng "interdiff"

 (gist.github.com/thoughtpolice)
3 điểm bởi GN⁺ 2024-09-12 | 1 bình luận | Chia sẻ qua WhatsApp

Vì sao một số người thích review mã bằng "interdiff"

Đánh giá công cụ review mã Gerrit

  • Gerrit là một công cụ review mã nguồn mở, hoạt động cùng với kho Git
  • Có thể viết patch trong kho và gửi lên để review
  • Người khác sẽ xem xét đoạn mã đã viết và chỉ ra những vấn đề cần sửa
  • Review mã nói chung là một ý tưởng tốt
  • Trong các dự án mã nguồn mở, mã có thể được hợp nhất, điều này làm tăng trách nhiệm và nợ kỹ thuật

Nhiều công cụ review mã khác nhau

  • Có nhiều công cụ như Gerrit, GitHub, Phabricator, tải tệp .patch lên bug tracker, gửi email qua git send-email, v.v.
  • Mỗi công cụ hoạt động hiệu quả ở những mức độ khác nhau

Chuỗi patch lý tưởng

  • Một chuỗi gồm 3 patch thể hiện sự tiến hóa của codebase theo từng bước
  • Các thay đổi nên được tách biệt một cách logic, và mỗi patch cần đọc như thể nó được áp dụng một cách độc lập
  • Review mã là quá trình xem xét chuỗi lý tưởng này

Cách GitHub review mã: "diff soup"

  • GitHub ban đầu khuyến khích review bằng cách thêm commit mới lên trên các commit gốc
  • Điều này xuất phát từ thiết kế UX và nhiều lý do khác
  • Khi nhiều commit được thêm vào trong quá trình review, mối quan hệ ngầm giữa các commit trở nên phức tạp
  • Việc dùng các công cụ git blame và git bisect trở nên khó khăn hơn

Cách tốt hơn: review "interdiff" (AKA git range-diff)

  • Thay vì thêm commit mới, hãy đăng một phiên bản mới của các commit gốc
  • Dùng git range-diff để so sánh sự khác biệt giữa các phiên bản commit
  • Reviewer có thể review theo phần tăng thêm mà không cần đọc lại toàn bộ diff
  • Các công cụ git blame và git bisect hoạt động đáng tin cậy hơn

Giải thích thêm: chiến lược hợp nhất patch

  • Cách trên là độc lập với chiến lược hợp nhất (ví dụ: git rebase so với commit git merge nhiều cha)

Giải thích thêm: liệu git rebase có xấu không

  • git rebase là ổn. Chỉ không nên dùng nó trên các nhánh công khai mà người khác sẽ dựa vào các commit đó

Ghi chú khác

Kết luận

  • Hệ thống review interdiff khuyến khích các patch nhỏ hơn và được hợp nhất vào nhánh chính nhanh hơn
  • Nó mang lại trải nghiệm review mã tốt hơn cho cả reviewer lẫn tác giả

Tóm tắt của GN⁺

  • Bài viết này đưa ra một phân tích chuyên sâu về các công cụ và phương pháp review mã
  • Cách review interdiff có thể cải thiện đáng kể hiệu quả của việc review mã
  • Nó giúp giải quyết vấn đề "diff soup" của GitHub
  • Bài viết nêu ra những yếu tố quan trọng cần cân nhắc khi chọn công cụ review mã
  • Các công cụ có chức năng tương tự gồm GitHub, Gerrit, Phabricator, v.v.

Bài viết liên quan

1 bình luận

 
GN⁺ 2024-09-12
Ý kiến Hacker News

  • Quy trình làm việc chủ yếu dùng trên GitHub có khối lượng thao tác lớn và không rõ ràng với cộng tác viên

    • Cho phép reviewer xem phần khác biệt sau khi đã tích hợp phản hồi mà không làm hỏng git blame và git bisect
    • Khi tích hợp phản hồi của reviewer, dùng git commit --fixup <hash của commit cần cập nhật>
    • Khi PR được duyệt, dùng git rebase --interactive origin/main --autosquash để gộp các commit fixup vào commit gốc
    • Cuối cùng dùng git push --force-with-lease để hợp nhất
    • Dùng tính năng tự động hoàn thành để nhập các lệnh dài dễ hơn

  • Cách review code của GitHub kém hiệu quả, và đã phải xử lý thủ công bằng Phabricator

    • Sẽ tốt hơn nếu có UI tường minh cho việc này

  • Muốn có một hệ thống tốt hơn cách review code của GitHub

    • Muốn hợp nhất nhanh các bản vá sửa lỗi nhỏ và thu hẹp phạm vi review
    • Có ý kiến cho rằng nên tách thành review/PR riêng, nhưng như vậy phát sinh vấn đề phụ thuộc giữa các patchset

  • Việc thấy những cách tiếp cận mới cho review code luôn rất thú vị

    • Đã cân nhắc việc chia patch thành các PR phụ thuộc riêng biệt
    • Các công cụ như GitContext có thể giúp giữ PR nhỏ trong khi vẫn duy trì quan hệ phụ thuộc
    • Có thể dùng AI để tóm tắt PR và review, đồng thời tạo commit message chính xác
    • Reviewer chỉ cần xem những thay đổi kể từ lần review gần nhất

  • Review Board là nơi đầu tiên đưa interdiffs vào, và nó rất hữu ích trong review code

    • Commit fix-it không phải là lựa chọn thay thế phù hợp
      1. Không thể biết các thay đổi ở thượng nguồn
      2. Làm biểu đồ commit trở nên phức tạp
      3. Không phải ai cũng dùng Git
    • interdiffs cho phép reviewer theo dõi mọi cập nhật kể từ yêu cầu review đầu tiên
    • Hữu ích khi đăng nhiều commit trong một yêu cầu review duy nhất

  • Đã có kinh nghiệm dùng hệ thống review code Gerrit, và cách review code của GitHub kém hiệu quả

    • Gerrit hỗ trợ xếp chồng nhiều patch, giúp review các patch nhỏ dễ hơn
    • Giao diện của GitHub trông như một luồng thảo luận diễn đàn và không thể theo dõi việc rebase

  • Đã dùng nhiều hệ thống review code khác nhau và mỗi hệ thống đều có ưu, nhược điểm riêng

    • Critique được tối ưu cho monorepo của Google và VCS tùy biến của họ
    • Gerrit tốt cho reviewer nhưng bất tiện với tác giả
    • GitHub thân thiện với tác giả nhưng kém hiệu quả với reviewer và cả nhóm
    • Việc dùng công cụ review code tốt hơn là rất quan trọng

  • Sau khi dùng hệ thống review code Gerrit, stack PR của GitHub trở nên bất tiện

    • GitHub không hiển thị đúng các thay đổi liên quan đến bình luận review code
    • Đã dùng một vài script để giúp làm việc với stack PR dễ hơn
    • Các công cụ như ejoffe/spr và spacedentist/spr rất hữu ích