Review code sao cho cả đội cùng giỏi lên chứ không nản lòng
Ở nhiều đội phát triển, review code bị coi như một thủ tục bắt buộc phải làm trước khi gộp nhánh: người viết hồi hộp chờ đợi, còn người review chỉ lướt qua vài dòng rồi bấm nút chấp thuận. Cách làm ấy bỏ phí một trong những cơ hội học hỏi tốt nhất mà một tập thể kỹ sư có thể tạo ra cho nhau. Khi được thực hiện tử tế, review code không chỉ giúp phát hiện lỗi sớm mà còn lan truyền kiến thức, thống nhất phong cách và nuôi dưỡng cảm giác cùng sở hữu sản phẩm. Bài viết này bàn về cách biến review code từ một nút thắt cổ chai gây ức chế thành một thói quen giúp mọi người cùng tiến bộ.
Mục đích thật sự của việc review
Trước khi bàn về kỹ thuật, cần thống nhất một điều: review code không phải là phiên tòa để chứng minh ai giỏi hơn ai. Mục tiêu của nó gồm nhiều lớp. Lớp gần nhất là bắt những lỗi mà chính tác giả không nhìn ra vì đã quá quen thuộc với đoạn mã của mình. Lớp sâu hơn là chia sẻ hiểu biết: khi bạn đọc code của đồng nghiệp, bạn học được cách họ tiếp cận vấn đề, và ngược lại. Lớp xa nhất, cũng quan trọng nhất, là xây dựng một chuẩn chung mà cả đội ngầm hiểu, để sáu tháng sau bất kỳ ai mở file lên cũng thấy quen thuộc thay vì lạc lối.
Khi hiểu rõ mục đích này, nhiều tranh cãi vô nghĩa sẽ tự biến mất. Bạn sẽ không còn sa đà vào việc cãi nhau nên xuống dòng ở đâu, mà tập trung vào những câu hỏi thật sự đáng giá: đoạn mã này có xử lý đúng trường hợp biên không, cái tên này có phản ánh đúng ý nghĩa không, liệu người đọc sau này có hiểu vì sao lại làm như vậy không.
Người viết cần chuẩn bị gì trước khi gửi
Một lần review tốt bắt đầu từ phía người gửi chứ không phải người đọc. Nếu bạn quăng cho đồng nghiệp một pull request khổng lồ với hai nghìn dòng thay đổi rải rác khắp nơi, đừng mong nhận lại phản hồi chất lượng. Não người có giới hạn, và một bản thay đổi càng lớn thì chất lượng review càng giảm nhanh. Người đọc sẽ mệt, sẽ lướt, và những lỗi tinh vi nhất sẽ trôi qua kẽ tay.
Vài thói quen giúp bản thay đổi của bạn dễ được review nghiêm túc:
- Giữ mỗi pull request nhỏ và tập trung vào một mục đích duy nhất, lý tưởng là dưới vài trăm dòng thay đổi.
- Viết phần mô tả rõ ràng: bạn đang giải quyết vấn đề gì, vì sao chọn cách này, và có phần nào bạn còn phân vân muốn được góp ý.
- Tự review lại code của mình một lượt trước khi gửi, để lọc bỏ những lỗi ngớ ngẩn và những dòng in thử còn sót lại.
- Chỉ ra sẵn những chỗ bạn muốn người khác chú ý, ví dụ một quyết định kiến trúc hoặc một đoạn xử lý phức tạp.
Khi bạn tôn trọng thời gian của người review bằng cách chuẩn bị chu đáo, họ sẽ đáp lại bằng những góp ý sâu sắc hơn nhiều.
Nghệ thuật viết nhận xét
Phần khó nhất của review không nằm ở kỹ thuật mà ở giao tiếp. Cùng một ý, cách diễn đạt khác nhau có thể khiến người nhận thấy được giúp đỡ hoặc thấy bị công kích. Nguyên tắc nền tảng là: nhận xét về đoạn code, đừng nhận xét về con người. Câu “hàm này đang lặp lại logic ở phía trên, gộp lại được không” nghe rất khác so với “sao bạn lại viết trùng lặp thế này”.
Một mẹo hữu ích là phân loại nhận xét theo mức độ. Có những điều bắt buộc phải sửa vì sẽ gây lỗi, có những điều chỉ là gợi ý cải thiện, và có những điều thuần túy là sở thích cá nhân. Nếu bạn ghi rõ “cái này chỉ là ý kiến riêng, không bắt buộc” thì người viết sẽ thoải mái hơn nhiều khi cân nhắc. Đừng để một góp ý nhỏ nhặt về dấu cách chặn đứng một pull request quan trọng chỉ vì nó nằm lẫn với các góp ý nghiêm túc mà không được phân biệt rõ.
Hãy đặt câu hỏi thay vì ra lệnh khi bạn chưa chắc chắn. Câu “ở đây nếu danh sách rỗng thì chuyện gì xảy ra nhỉ” vừa lịch sự vừa buộc tác giả tự suy nghĩ, thay vì áp đặt một kết luận có thể sai vì bạn chưa nắm hết bối cảnh của họ.
Người nhận cũng cần tâm thế đúng
Nhận phản hồi về code của mình không bao giờ dễ chịu hoàn toàn, nhất là khi bạn đã dồn nhiều công sức vào đó. Nhưng điều quan trọng cần nhớ là: người ta góp ý cho code chứ không phải chấm điểm giá trị của bạn với tư cách một con người. Một kỹ sư trưởng thành tách được cái tôi ra khỏi dòng code mình viết, và xem mỗi nhận xét như một dữ liệu để cân nhắc chứ không phải một lời phán xét.
Nếu bạn không đồng ý với một góp ý, hãy trả lời bằng lý lẽ thay vì im lặng sửa cho xong hoặc phòng thủ gay gắt. Có khi chính cuộc trao đổi đó lại làm lộ ra một hiểu lầm hoặc một yêu cầu ẩn mà cả hai đều chưa thấy. Và khi một nhận xét lặp đi lặp lại giữa các lần review, đó là tín hiệu để bạn biến nó thành một quy tắc chung, hoặc tốt hơn nữa, để công cụ tự động kiểm tra thay cho con người.
Đưa review vào nhịp làm việc của đội
Review code chỉ phát huy tác dụng khi nó diễn ra kịp thời. Một pull request nằm chờ ba ngày sẽ chặn đứng công việc của người khác và khiến chính tác giả quên mất bối cảnh mình vừa làm. Nhiều đội đặt ra thỏa thuận ngầm rằng review nên được phản hồi trong vòng vài giờ làm việc, và ưu tiên việc mở khóa cho đồng nghiệp hơn là lao đầu vào task mới của bản thân.
Đồng thời, hãy để máy móc làm phần việc của máy móc. Định dạng code, kiểm tra lỗi cú pháp, chạy bộ kiểm thử nên được tự động hóa hoàn toàn để con người dành sức cho những điều máy không làm được: đánh giá thiết kế, cân nhắc trường hợp biên, và truyền lại kinh nghiệm. Khi cả đội cùng xem review là nơi để học và dạy lẫn nhau chứ không phải một cửa ải phải vượt qua, chất lượng mã nguồn và tình đồng đội sẽ cùng nhau đi lên.
