Critique - Cách Google giảm bớt nỗi đau code review với mức độ hài lòng 97% từ lập trình viên

xguru · 2023-12-11T10:32:02+09:00

Nhiều cựu Googler rất nhớ công cụ code review của Google là "Critique" Theo khảo sát nội bộ của Google, 97% lập trình viên hài lòng với Critique Hướng dẫn code review của Google Khuyến khích cải tiến liên tục hơn là sự hoàn hảo Duy trì hoặc cải thiện trạng thái của codebase Tuân theo style guide Luôn chia sẻ kiến thức: khuyến khích chia sẻ kiến thức về tính năng ngôn ngữ, codebase và các artifact liên quan khác thông qua code review Viết thay đổi nhỏ gọn (khoảng 200 dòng) Tiêu chuẩn nghiêm ngặt về tính gọn nhẹ (review thay đổi mã trong vòng 24 giờ, lý tưởng là chỉ một reviewer) Lịch sự và chuyên nghiệp: điều quan trọng là duy trì văn hóa tin cậy và tôn trọng Critique: công cụ code review của Google Giúp kỹ sư review và gửi các thay đổi mã một cách hiệu quả Theo bài nghiên cứu gần đây - Resolving code review comments with ML, Google đang sử dụng một công cụ code review toàn diện dựa trên AI Khi reviewer để lại bình luận trên mã, Critique sẽ hiển thị đề xuất chỉnh sửa dựa trên ML Tác giả code review chỉ cần bấm một nút là có thể áp dụng chỉnh sửa trên diện rộng cho bình luận đó Luồng code review Bước 1: Tạo thay đổi CL (hoặc Pull Request) được tạo trong Cider, trình chỉnh sửa mã nội bộ của Google Được tích hợp chặt chẽ với Critique và các công cụ nội bộ khác của Google để nâng cao năng suất cho lập trình viên Công cụ Prereview: tinh chỉnh thay đổi trước khi review, hiển thị diff, kết quả build và test, cũng như kiểm tra style Chế độ xem và trực quan hóa Diff: tô sáng cú pháp, tham chiếu chéo, intraline diffing, bỏ qua khoảng trắng, phát hiện di chuyển Hiển thị kết quả từ static analyzer để làm nổi bật các kết quả quan trọng và đưa ra đề xuất sửa. Bao gồm cả "presubmits", tức các bài test tự động chạy trong Critique Bước 2: Yêu cầu review Khi pull request đã sẵn sàng để review, tác giả mã sẽ thêm reviewer và chính thức gửi đi để được review Khi PR/CL được gửi để review, "Presubmits" sẽ chạy nếu chưa có trên ảnh chụp mã hiện tại. Nhờ vậy, mọi người tham gia review đều biết liệu mã có vấn đề hay không Cũng có thể ẩn danh code review để tác giả mã được giữ ẩn danh với reviewer. Tuy nhiên, Google không tìm thấy khác biệt hữu ích nào giữa code review ẩn danh và code review 'thực' Bước 3 và 4: Hiểu thay đổi và để lại bình luận Bất kỳ ai cũng có thể bình luận về thay đổi, đồng thời có các tính năng theo dõi tiến độ review và xử lý bình luận Bình luận chưa được xử lý thể hiện hạng mục công việc mà tác giả thay đổi chắc chắn phải giải quyết. Các bình luận này có thể được đánh dấu là 'đã xử lý' khi tác giả mã trực tiếp trả lời bình luận Các bình luận đã xử lý có thể bao gồm những nhận xét mang tính tùy chọn hoặc cung cấp thông tin mà tác giả thay đổi có thể không cần hành động Có dashboard để kiểm tra trạng thái review và "Attention Set" để cho những người tham gia một code review cụ thể biết hiện đang chờ ai hành động Bước 5: Phê duyệt thay đổi Như đã đề cập ở trên, để review được ghi nhận thì phải nhận được LGTM (Looks Good To Me) từ ít nhất một reviewer Dù tác giả mã có thể trực tiếp đánh dấu bình luận là đã xử lý khi phản hồi, số bình luận chưa xử lý vẫn phải bằng 0 Ngoài ra còn cần sự phê duyệt của owner của phần codebase liên quan và phê duyệt về readability Tất cả những việc này có thể do một reviewer thực hiện Bước 6: Commit thay đổi Gửi và commit thay đổi ngay trong Critique Critique vẫn hữu ích ngay cả sau khi thay đổi đã được gửi "Các nhà nghiên cứu của Google đã tìm thấy bằng chứng mạnh mẽ rằng công dụng của Critique vượt ra ngoài code review. Tác giả thay đổi dùng Critique để xem lại diff và kiểm tra kết quả từ các công cụ phân tích. Trong một số trường hợp, code review là một phần của quy trình phát triển thay đổi, nơi reviewer có thể gửi các thay đổi chưa hoàn thiện để quyết định cách hoàn tất việc triển khai. Ngoài ra, lập trình viên còn dùng Critique để xem lại lịch sử của các thay đổi đã được gửi ngay cả sau khi chúng đã được phê duyệt." Thống kê code review mới nhất của Google Tần suất tạo thay đổi: Trung vị: 3 thay đổi mỗi tuần 80% tác giả tạo dưới 7 thay đổi mỗi tuần Tần suất review: Trung vị: review 4 thay đổi mỗi tuần 80% reviewer xử lý dưới 10 thay đổi mỗi tuần Thời gian dành cho review mỗi tuần: Trung bình 3,2 giờ mỗi tuần Trung vị 2,6 giờ mỗi tuần Thời gian chờ phản hồi ban đầu: Thay đổi nhỏ: trung bình dưới 1 giờ Thay đổi rất lớn: khoảng 5 giờ Tổng thời gian của quy trình review: Độ trễ trung bình cho mọi kích thước mã: dưới 4 giờ So sánh với các công ty khác: AMD: 17,5 giờ (trung vị thời gian đến khi được phê duyệt) Chrome OS: 15,7 giờ Các dự án của Microsoft: 14,7 giờ, 19,8 giờ, 18,9 giờ Microsoft (nghiên cứu khác): 24 giờ Vì sao Googler yêu thích Critique? Phân tích tĩnh: sở hữu bộ công cụ static analysis đầy đủ tính năng, tự động cung cấp phản hồi có thể hành động trực tiếp cho mã. Nhờ đó, cả tác giả mã lẫn reviewer đều tiết kiệm thời gian, reviewer không cần chỉ ra từng lỗi hiển nhiên Chỉ tập trung vào file được thay đổi gần nhất: có thể chỉ tập trung vào 'ảnh chụp' mới nhất của mã. Snapshot trước đó, commit và thay đổi mã cũ không hiển thị, giúp giao diện sạch sẽ hơn Giao diện side-by-side diff quen thuộc: mặc định hiển thị "khác với lần review trước" Đề xuất dựa trên machine learning: tính năng đề xuất mới dựa trên ML của Google giúp tăng tốc code review đáng kể Tích hợp chặt chẽ với các công cụ khác của Google: Critique tích hợp rất tốt với các công cụ nội bộ khác như IDE và bug tracker của Google, giúp tăng năng suất. Điều này bao gồm liên kết dễ dàng giữa code, bình luận và ticket Theo dõi 'work set': giúp biết ai là người cần thực hiện bước tiếp theo Gamification thú vị: dù Critique không được thiết kế để mang tính game hóa, các Googler nói rằng họ rất thích khi Critique 'chuyển sang màu xanh' và PR sẵn sàng để gửi (mọi bài test đều qua, reviewer đã LGTM) Các bình luận trên Reddit Các phím tắt bàn phím tuyệt vời giúp review một lượng lớn mã rất hiệu quả Mặc định hiển thị "khác với lần review trước" Có tính năng "phát hiện mã di chuyển" nên có thể tập trung vào những thay đổi của mã Cung cấp tính năng tuyệt vời cho biết ai cần phải hành động, dù là reviewer hay tác giả Khi dùng cùng tiện ích mở rộng Chrome, có thể dễ dàng nhận thông báo và kiểm tra hàng đợi review Bất kỳ ai trong nội bộ cũng có thể chạy truy vấn trên dữ liệu code review để thu thập insight Tự động liên kết giữa code và bình luận (bao gồm ticket và việc di chuyển/liên kết) Có thể xem phân tích, lịch sử và bình luận của PR ở dạng bảng, giúp hiểu tiến độ của PR có nhiều vòng chỉnh sửa mã dễ dàng hơn nhiều Thuật ngữ/thẻ của bình luận như tùy chọn, ghi chú, v.v. rất nhất quán Suy nghĩ và hàm ý Nhiều tính năng này hiện cũng có ở các công cụ khác, nhưng lý do công cụ này được yêu thích có lẽ là nhờ sự tích hợp chặt chẽ và mức độ 'cá nhân hóa' cực cao với workflow cũng như codebase riêng của Google Đồng thời, điều đó cũng có nghĩa là về mặt thực tế, không công ty nào có thể sao chép chính xác Critique và các công cụ liên quan. Ví dụ, một số công cụ được tối ưu riêng cho các vấn đề phát sinh từ cấu trúc monorepo Dù bản thân Critique có lẽ sẽ không được open source, Gerrit là một công cụ tương tự Critique. Đây cũng là công cụ review mã nguồn mở do Google tạo ra và duy trì Tuy vậy, có thể thấy Google đầu tư rất nhiều công sức và suy nghĩ cho năng suất của lập trình viên. Họ tự do công bố các nghiên cứu của mình, và chúng ta có thể rút ra nhiều hàm ý hữu ích từ công việc đó

(engineercodex.substack.com)

52 điểm bởi xguru 2023-12-11 | 5 bình luận | Chia sẻ qua WhatsApp

Nhiều cựu Googler rất nhớ công cụ code review của Google là "Critique"
Theo khảo sát nội bộ của Google, 97% lập trình viên hài lòng với Critique

Hướng dẫn code review của Google

Khuyến khích cải tiến liên tục hơn là sự hoàn hảo
Duy trì hoặc cải thiện trạng thái của codebase
Tuân theo style guide
Luôn chia sẻ kiến thức: khuyến khích chia sẻ kiến thức về tính năng ngôn ngữ, codebase và các artifact liên quan khác thông qua code review
Viết thay đổi nhỏ gọn (khoảng 200 dòng)
Tiêu chuẩn nghiêm ngặt về tính gọn nhẹ (review thay đổi mã trong vòng 24 giờ, lý tưởng là chỉ một reviewer)
Lịch sự và chuyên nghiệp: điều quan trọng là duy trì văn hóa tin cậy và tôn trọng

Critique: công cụ code review của Google

Giúp kỹ sư review và gửi các thay đổi mã một cách hiệu quả
Theo bài nghiên cứu gần đây - Resolving code review comments with ML, Google đang sử dụng một công cụ code review toàn diện dựa trên AI
- Khi reviewer để lại bình luận trên mã, Critique sẽ hiển thị đề xuất chỉnh sửa dựa trên ML
- Tác giả code review chỉ cần bấm một nút là có thể áp dụng chỉnh sửa trên diện rộng cho bình luận đó

Luồng code review

Bước 1: Tạo thay đổi
- CL (hoặc Pull Request) được tạo trong Cider, trình chỉnh sửa mã nội bộ của Google
- Được tích hợp chặt chẽ với Critique và các công cụ nội bộ khác của Google để nâng cao năng suất cho lập trình viên
- Công cụ Prereview: tinh chỉnh thay đổi trước khi review, hiển thị diff, kết quả build và test, cũng như kiểm tra style
- Chế độ xem và trực quan hóa Diff: tô sáng cú pháp, tham chiếu chéo, intraline diffing, bỏ qua khoảng trắng, phát hiện di chuyển
- Hiển thị kết quả từ static analyzer để làm nổi bật các kết quả quan trọng và đưa ra đề xuất sửa. Bao gồm cả "presubmits", tức các bài test tự động chạy trong Critique
Bước 2: Yêu cầu review
- Khi pull request đã sẵn sàng để review, tác giả mã sẽ thêm reviewer và chính thức gửi đi để được review
- Khi PR/CL được gửi để review, "Presubmits" sẽ chạy nếu chưa có trên ảnh chụp mã hiện tại. Nhờ vậy, mọi người tham gia review đều biết liệu mã có vấn đề hay không
- Cũng có thể ẩn danh code review để tác giả mã được giữ ẩn danh với reviewer. Tuy nhiên, Google không tìm thấy khác biệt hữu ích nào giữa code review ẩn danh và code review 'thực'
Bước 3 và 4: Hiểu thay đổi và để lại bình luận
- Bất kỳ ai cũng có thể bình luận về thay đổi, đồng thời có các tính năng theo dõi tiến độ review và xử lý bình luận
- Bình luận chưa được xử lý thể hiện hạng mục công việc mà tác giả thay đổi chắc chắn phải giải quyết. Các bình luận này có thể được đánh dấu là 'đã xử lý' khi tác giả mã trực tiếp trả lời bình luận
- Các bình luận đã xử lý có thể bao gồm những nhận xét mang tính tùy chọn hoặc cung cấp thông tin mà tác giả thay đổi có thể không cần hành động
- Có dashboard để kiểm tra trạng thái review và "Attention Set" để cho những người tham gia một code review cụ thể biết hiện đang chờ ai hành động
Bước 5: Phê duyệt thay đổi
- Như đã đề cập ở trên, để review được ghi nhận thì phải nhận được LGTM (Looks Good To Me) từ ít nhất một reviewer
- Dù tác giả mã có thể trực tiếp đánh dấu bình luận là đã xử lý khi phản hồi, số bình luận chưa xử lý vẫn phải bằng 0
- Ngoài ra còn cần sự phê duyệt của owner của phần codebase liên quan và phê duyệt về readability
- Tất cả những việc này có thể do một reviewer thực hiện
Bước 6: Commit thay đổi
- Gửi và commit thay đổi ngay trong Critique
- Critique vẫn hữu ích ngay cả sau khi thay đổi đã được gửi
- "Các nhà nghiên cứu của Google đã tìm thấy bằng chứng mạnh mẽ rằng công dụng của Critique vượt ra ngoài code review. Tác giả thay đổi dùng Critique để xem lại diff và kiểm tra kết quả từ các công cụ phân tích. Trong một số trường hợp, code review là một phần của quy trình phát triển thay đổi, nơi reviewer có thể gửi các thay đổi chưa hoàn thiện để quyết định cách hoàn tất việc triển khai. Ngoài ra, lập trình viên còn dùng Critique để xem lại lịch sử của các thay đổi đã được gửi ngay cả sau khi chúng đã được phê duyệt."

Thống kê code review mới nhất của Google

Tần suất tạo thay đổi:
- Trung vị: 3 thay đổi mỗi tuần
- 80% tác giả tạo dưới 7 thay đổi mỗi tuần
Tần suất review:
- Trung vị: review 4 thay đổi mỗi tuần
- 80% reviewer xử lý dưới 10 thay đổi mỗi tuần
Thời gian dành cho review mỗi tuần:
- Trung bình 3,2 giờ mỗi tuần
- Trung vị 2,6 giờ mỗi tuần
Thời gian chờ phản hồi ban đầu:
- Thay đổi nhỏ: trung bình dưới 1 giờ
- Thay đổi rất lớn: khoảng 5 giờ
Tổng thời gian của quy trình review:
- Độ trễ trung bình cho mọi kích thước mã: dưới 4 giờ
- So sánh với các công ty khác:
  - AMD: 17,5 giờ (trung vị thời gian đến khi được phê duyệt)
  - Chrome OS: 15,7 giờ
  - Các dự án của Microsoft: 14,7 giờ, 19,8 giờ, 18,9 giờ
  - Microsoft (nghiên cứu khác): 24 giờ

Vì sao Googler yêu thích Critique?

Phân tích tĩnh: sở hữu bộ công cụ static analysis đầy đủ tính năng, tự động cung cấp phản hồi có thể hành động trực tiếp cho mã. Nhờ đó, cả tác giả mã lẫn reviewer đều tiết kiệm thời gian, reviewer không cần chỉ ra từng lỗi hiển nhiên
Chỉ tập trung vào file được thay đổi gần nhất: có thể chỉ tập trung vào 'ảnh chụp' mới nhất của mã. Snapshot trước đó, commit và thay đổi mã cũ không hiển thị, giúp giao diện sạch sẽ hơn
Giao diện side-by-side diff quen thuộc: mặc định hiển thị "khác với lần review trước"
Đề xuất dựa trên machine learning: tính năng đề xuất mới dựa trên ML của Google giúp tăng tốc code review đáng kể
Tích hợp chặt chẽ với các công cụ khác của Google: Critique tích hợp rất tốt với các công cụ nội bộ khác như IDE và bug tracker của Google, giúp tăng năng suất. Điều này bao gồm liên kết dễ dàng giữa code, bình luận và ticket
Theo dõi 'work set': giúp biết ai là người cần thực hiện bước tiếp theo
Gamification thú vị: dù Critique không được thiết kế để mang tính game hóa, các Googler nói rằng họ rất thích khi Critique 'chuyển sang màu xanh' và PR sẵn sàng để gửi (mọi bài test đều qua, reviewer đã LGTM)
Các bình luận trên Reddit
- Các phím tắt bàn phím tuyệt vời giúp review một lượng lớn mã rất hiệu quả
- Mặc định hiển thị "khác với lần review trước"
- Có tính năng "phát hiện mã di chuyển" nên có thể tập trung vào những thay đổi của mã
- Cung cấp tính năng tuyệt vời cho biết ai cần phải hành động, dù là reviewer hay tác giả
- Khi dùng cùng tiện ích mở rộng Chrome, có thể dễ dàng nhận thông báo và kiểm tra hàng đợi review
- Bất kỳ ai trong nội bộ cũng có thể chạy truy vấn trên dữ liệu code review để thu thập insight
- Tự động liên kết giữa code và bình luận (bao gồm ticket và việc di chuyển/liên kết)
- Có thể xem phân tích, lịch sử và bình luận của PR ở dạng bảng, giúp hiểu tiến độ của PR có nhiều vòng chỉnh sửa mã dễ dàng hơn nhiều
- Thuật ngữ/thẻ của bình luận như tùy chọn, ghi chú, v.v. rất nhất quán

Suy nghĩ và hàm ý

Nhiều tính năng này hiện cũng có ở các công cụ khác, nhưng lý do công cụ này được yêu thích có lẽ là nhờ sự tích hợp chặt chẽ và mức độ 'cá nhân hóa' cực cao với workflow cũng như codebase riêng của Google
Đồng thời, điều đó cũng có nghĩa là về mặt thực tế, không công ty nào có thể sao chép chính xác Critique và các công cụ liên quan. Ví dụ, một số công cụ được tối ưu riêng cho các vấn đề phát sinh từ cấu trúc monorepo
Dù bản thân Critique có lẽ sẽ không được open source, Gerrit là một công cụ tương tự Critique. Đây cũng là công cụ review mã nguồn mở do Google tạo ra và duy trì
Tuy vậy, có thể thấy Google đầu tư rất nhiều công sức và suy nghĩ cho năng suất của lập trình viên. Họ tự do công bố các nghiên cứu của mình, và chúng ta có thể rút ra nhiều hàm ý hữu ích từ công việc đó

5 bình luận

xguru 2023-12-17

Hình như cũng đã có những nỗ lực gắn ChatGPT vào Gerrit rồi
https://github.com/xielong/chatgpt-code-review-gerrit-plugin

kkweon 2023-12-12

Điểm mình cảm nhận rõ nhất là ở Critique có thể review một chuỗi các CL liên tiếp. Trên GitHub thì việc không hỗ trợ trực tiếp PR chain khá bất tiện. Vì thế либо phải gộp thành một PR lớn, либо phải đợi PR trước được merge.

tested 2023-12-11

GitHub cũng có cái tương tự, không biết khi nào sẽ mở cho công chúng
> https://githubnext.com/projects/copilot-for-pull-requests

winterjung 2023-12-11

Không có phân tích tĩnh hay các đề xuất dựa trên ML, nhưng đọc bài thì thấy khá giống với tính năng review của GitHub. Với tư cách là người dùng review của GitHub rất nhiều, tôi cũng mong các tính năng khác mà Critique cung cấp sẽ được đưa vào nhiều hơn.

xguru 2023-12-11

Hướng dẫn code review của Google [bản dịch tiếng Hàn]