Code review có thể tốt hơn

• Các lập trình viên đang cảm thấy rất không hài lòng với trải nghiệm code review của GitHub, và đang thử những cách tiếp cận mới để cải thiện điều đó
• Một công cụ thử nghiệm tên là git-review được thiết kế để xử lý review cùng với mã trực tiếp ở môi trường cục bộ, thay vì qua giao diện web trên trình duyệt
• Review được quản lý bằng một commit duy nhất; các bình luận review được để lại như chú thích trong mã, rồi reviewer và tác giả cùng nhau chỉnh sửa commit đó
• Tuy nhiên, nếu mã bị sửa hoặc bị rebase trong lúc review, sẽ phát sinh bất tiện lớn trong xử lý xung đột và khi dùng --force-with-lease, nên cách này không đạt được thành công lớn
• Cuối cùng mọi người quay lại review trên web, nhưng ý tưởng đưa trạng thái review trực tiếp vào kho Git vẫn rất hấp dẫn, và cùng với các cải tiến Git trong tương lai như Gerrit-style Change-Id, vẫn có khả năng xuất hiện phương án tốt hơn

---

Nhận diện vấn đề với hệ thống code review

• Hiện nay rất nhiều người không hài lòng với quy trình code review của GitHub
• Các vấn đề chính là thiếu hỗ trợ cho stacked pull request và interdiff review, đồng thời
  • Trạng thái review không được lưu trong kho
  • Việc review qua giao diện web ưu tiên từ xa là bắt buộc
• Vấn đề tôi thấy là thiếu tính phi tập trung trong review và sự kém hiệu quả của giao diện

So sánh workflow viết mã và review

• Khi viết mã, mọi người dùng trình soạn thảo ở môi trường cục bộ
  • Độ trễ bộ nhớ và NVMe thấp, đồng thời môi trường này được tối ưu cho workflow riêng của từng người dùng
• Với code review, tôi cũng thích cách pull source branch về cục bộ để làm việc
  • Với các công cụ như Magit, có thể khám phá không chỉ diff mà còn cả ngữ cảnh đầy đủ của mã
  • Có thể tận dụng môi trường phát triển mạnh mẽ như chạy test, nhảy đến định nghĩa mã, thử refactor, v.v.
• Trong khi đó, để để lại phản hồi trên PR, lại phải chuyển sang trình duyệt và dùng giao diện web chậm chạp; với diff lớn còn có độ trễ khi nhập liệu

Giao diện code review và cấu trúc lưu trữ lý tưởng

• Trên thực tế, việc để lại bình luận inline trong mã hoặc trực tiếp sửa mã là tự nhiên nhất

  // CR(matklad): Hm, this check seems imprecise to me.  
  // Shouldn't we compare `replica.view` instead of `header.view` here?  
  if (header.view != view) return;  
  

• Khi dữ liệu được lưu trong DB từ xa thay vì kho git cục bộ, các vấn đề về độ trễ và vendor lock-in cũng phát sinh

Ý tưởng của git-review và trải nghiệm thực tế

• Ý tưởng của git-review như sau:
  • Code review được thực hiện bằng một commit duy nhất ở đỉnh của nhánh PR
  • Commit đó được thêm các bình luận mã với marker đặc biệt
  • Reviewer và tác giả lần lượt chỉnh sửa commit này, cộng tác dựa trên push --force-with-lease
  • Mọi bình luận đều được đánh dấu đã giải quyết (//? resolved) và khi review kết thúc sẽ thêm revert commit để lưu lại lịch sử
• Ý tưởng này đơn giản và thực tế, nhưng trong triển khai thực tế đã gặp các vấn đề sau
  • Khi mã thay đổi trong lúc review, rất thường xuyên xảy ra xung đột giữa bình luận với các commit phía dưới hoặc commit mới
  • Quá trình force-push làm tăng ma sát khi cộng tác và độ phức tạp công việc
  • Rất khó xử lý sự không khớp giữa lịch sử thay đổi của mã và tiến trình review, cũng như quản lý xung đột khi hợp nhất

Những thay đổi mới và khả năng trong tương lai

• Trong tương lai, Change-Id kiểu Gerrit có thể được đưa vào Git upstream
  • Điều này sẽ giúp dễ theo dõi lịch sử chỉnh sửa theo từng commit hơn, từ đó mở rộng hỗ trợ cho interdiff review
  • Tuy nhiên, điều này được dự đoán là sẽ có một phần xung đột với cách làm của git-review
  • Với cấu trúc Change-Id mới, có thể xuất hiện những cách tiếp cận khác lạ như thêm bình luận review trực tiếp vào chính commit

Kết luận và giới thiệu một số hệ thống đáng tham khảo

• Cuối cùng, ở thời điểm hiện tại mọi thứ lại quay về code review dựa trên giao diện web
• Nhu cầu về một giải pháp tốt hơn vẫn còn nguyên
• Giới thiệu một số hệ thống và công cụ liên quan đáng tham khảo
  • Fossil: hệ thống SCM lưu toàn bộ thông tin bên trong kho
  • NoteDb: tích hợp lịch sử lưu trạng thái review của Gerrit vào git
  • git-bug: lưu thông tin issue trong git
  • git-appraise: lưu thông tin review ngay trong git
  • prr: triển khai giao diện review trong editor bằng cách tích hợp với GitHub API
  • How Jane Street Does Code Review: ví dụ về một thực tiễn tốt hơn trong đời thực
  • git-pr: dự án thay thế toàn bộ workflow PR bằng các tính năng gốc của git

Kết lại

• Hiện vẫn chưa có một lời giải hoàn hảo, và các nỗ lực nhằm mang lại trải nghiệm tốt hơn cho lập trình viên vẫn đang tiếp diễn
• Có rất nhiều kỳ vọng vào hướng phát triển trong tương lai