Khi bàn về việc reviewer nên reject, khi nào nên request change và khi nào nên cho merge, điều quan trọng nhất không phải là cảm tính của người review mà là quy tắc cộng tác của cả đội. Với Midi Coder và cách làm contract-first, mục tiêu không phải loại bỏ con người khỏi quy trình, mà là tái phân vai để mỗi người chịu trách nhiệm đúng chỗ, đúng thời điểm và có traceability rõ ràng.
Review không chỉ là kiểm tra code
Trong cách làm truyền thống, nhiều đội xem review là bước cuối để một senior hoặc Tech Lead đọc code và quyết định có cho lên nhánh chính hay không. Cách này dễ dẫn đến ba vấn đề: reviewer phải gánh quá nhiều quyết định, tranh luận bị kéo dài vì không có mốc tham chiếu chung, và lỗi trách nhiệm bị đẩy qua lại giữa BA, PM, Developer và người review.
Với Midi Coder, review được đặt trong một chuỗi rõ ràng: brief được khóa, contract được khóa, phần triển khai bám theo version, và mỗi thay đổi đều có lý do. Khi đó, reviewer không phải là người “phán xử toàn bộ”, mà là người xác nhận xem thay đổi có đúng phạm vi đã cam kết hay không, có vi phạm contract không, có làm sai traceability giữa yêu cầu và implementation không.
Phân vai giữa BA, PM, Tech Lead, Developer và reviewer
- BA chịu trách nhiệm làm rõ yêu cầu nghiệp vụ, phạm vi, tiêu chí chấp nhận và các trường hợp biên. BA không nên để phần diễn giải mơ hồ rồi đẩy sang reviewer tự đoán.
- PM chịu trách nhiệm ưu tiên, quyết định trade-off về thời gian, phạm vi và phối hợp giữa các vai trò. PM không thay Tech Lead quyết định kỹ thuật, nhưng phải đảm bảo luồng ra quyết định không bị tắc.
- Tech Lead chịu trách nhiệm khóa hướng kỹ thuật, chuẩn kiến trúc, ràng buộc tích hợp, tiêu chuẩn chất lượng và contract kỹ thuật nếu có. Đây là điểm then chốt của contract coding.
- Developer chịu trách nhiệm triển khai đúng brief đã được chốt, đúng contract đã được khóa, tự kiểm tra trước khi mở review và mô tả rõ phần nào là thay đổi có chủ đích.
- Reviewer chịu trách nhiệm kiểm tra mức độ phù hợp giữa thay đổi và những gì đã được chốt. Reviewer không nên tự ý mở rộng scope, cũng không nên bỏ qua sai lệch chỉ vì code “chạy được”.
Ai khóa brief, ai khóa contract, ai áp dụng thay đổi?
Đây là chỗ nhiều đội nhỏ thường nhầm. Nếu không khóa rõ, mọi cuộc review sẽ biến thành tranh luận vô tận.
- Khóa brief: BA hoặc PM, tùy cấu trúc đội, nhưng phải có người sở hữu cuối cùng. Khi brief đã khóa, mọi thay đổi phạm vi cần được ghi nhận thành version mới.
- Khóa contract: Tech Lead hoặc người chịu trách nhiệm kỹ thuật. Contract ở đây có thể là API shape, data model, input/output, naming rules, error behavior, luồng xử lý hoặc các tiêu chuẩn interface giữa các phần.
- Áp dụng thay đổi: Developer triển khai thay đổi, nhưng chỉ sau khi thay đổi đó được chấp thuận đúng vai. Nếu thay đổi liên quan nghiệp vụ, BA/PM phải xác nhận. Nếu liên quan kỹ thuật và interface, Tech Lead phải xác nhận.
Nói ngắn gọn: reviewer không phải người tự phát minh brief mới hay contract mới trong lúc review. Reviewer dùng các bản đã khóa để đánh giá. Nếu phát hiện brief hoặc contract có vấn đề, reviewer có quyền chặn merge, nhưng việc sửa nguồn gốc phải quay về đúng người chịu trách nhiệm.
Khi nào nên reject?
Reject nên dùng khi thay đổi sai nền tảng hoặc sai quy trình đến mức không thể tiếp tục review như một chỉnh sửa nhỏ. Một số trường hợp điển hình:
- Code đi ngược brief đã khóa hoặc triển khai một hiểu khác hoàn toàn so với yêu cầu.
- Thay đổi phá vỡ contract đã chốt mà không có version mới hoặc không có quyết định chính thức từ Tech Lead.
- PR trộn nhiều mục tiêu khác nhau, làm mất traceability giữa yêu cầu, thiết kế và code.
- Thiếu bằng chứng tự kiểm tra cơ bản, thiếu mô tả phạm vi thay đổi, hoặc reviewer không thể xác định được thay đổi đang giải quyết yêu cầu nào.
- Có rủi ro chất lượng nghiêm trọng: sai logic chính, sai dữ liệu, ảnh hưởng bảo mật, phá vỡ tương thích hoặc gây lỗi hệ thống.
Reject không phải để “thể hiện quyền lực”. Reject là tín hiệu rằng vấn đề nằm ở mức cần quay lại bước trước: làm rõ yêu cầu, khóa lại contract hoặc tách PR cho đúng. Nếu reviewer cứ cố request change trong những trường hợp này, cả đội sẽ mất thời gian vì đang sửa triệu chứng chứ không sửa nguyên nhân.
Khi nào nên request change?
Request change phù hợp khi hướng đi tổng thể là đúng, nhưng vẫn còn điểm cần chỉnh trước khi merge. Ví dụ:
- Triển khai đúng yêu cầu nhưng thiếu một số edge case đã có trong brief.
- Code đúng contract nhưng cách tổ chức còn khó đọc, thiếu test, thiếu xử lý lỗi hoặc thiếu tài liệu giải thích.
- Tên biến, cấu trúc hàm, logging, kiểm soát null, validation hoặc tiêu chuẩn formatting chưa đạt chuẩn của đội.
- Reviewer phát hiện inconsistency nhỏ giữa mô tả PR và implementation, nhưng không cần quay lại bước phân tích phạm vi.
- Cần tách commit hoặc làm sạch thay đổi để dễ audit và dễ trace về sau.
Request change là quyết định hiệu quả nhất khi vấn đề có thể được giải quyết trong cùng một intent ban đầu. Nói cách khác, không cần viết lại brief hay đổi contract; chỉ cần sửa cho tròn trách nhiệm triển khai.
Khi nào nên cho merge?
Cho merge khi thay đổi đáp ứng đủ ba điều kiện:
- Đúng brief hoặc đúng version brief hiện hành.
- Đúng contract hoặc đúng version contract hiện hành.
- Đạt mức chất lượng tối thiểu mà đội đã thống nhất.
Điều này không có nghĩa là code phải hoàn hảo tuyệt đối. Một reviewer giỏi hiểu rằng merge là quyết định theo tiêu chuẩn đã chốt, không phải theo sở thích cá nhân. Nếu mọi ý kiến chỉ còn là “có thể tốt hơn”, “anh thường làm kiểu khác”, “em thích đặt tên cách này hơn”, thì đó là góp ý tùy chọn chứ không nên chặn merge.
Vì sao quy trình theo version giúp đội phối hợp rõ hơn?
Khi brief và contract được quản lý theo version, cả đội có một điểm tham chiếu chung. Điều này tạo ra ba lợi ích rất lớn:
- Giảm tranh cãi cảm tính: thay vì cãi xem ai hiểu đúng, mọi người so với bản đang có hiệu lực.
- Tăng traceability: có thể lần ngược từ yêu cầu sang contract, từ contract sang code, từ code sang quyết định review.
- Làm rõ trách nhiệm: nếu lỗi do brief thiếu, BA/PM cần cập nhật; nếu lỗi do contract mơ hồ, Tech Lead cần sửa; nếu lỗi do triển khai sai, Developer cần chỉnh; reviewer chỉ là người phát hiện và xác nhận.
Đây là tinh thần của software factory: không biến con người thành mắt xích máy móc, mà giúp đội phối hợp trên các đầu vào và đầu ra rõ ràng, có thể kiểm chứng.
Mẫu chia việc cho một đội nhỏ lần đầu dùng Midicoder
Với một đội nhỏ, cách bắt đầu thực tế có thể như sau:
- BA/PM: viết brief ngắn, khóa mục tiêu, tiêu chí chấp nhận, phạm vi không làm.
- Tech Lead: viết contract kỹ thuật tối thiểu, nêu rõ interface, dữ liệu, ràng buộc, version.
- Developer: triển khai theo contract, tự check các tiêu chí và ghi chú phần nào bám brief, phần nào bám contract.
- Reviewer: review theo checklist: đúng brief chưa, đúng contract chưa, có sai version không, có rủi ro chất lượng nghiêm trọng không.
- PM: nếu có thay đổi scope trong lúc làm, không sửa miệng trong chat rồi bắt dev tự hiểu; phải tạo version mới hoặc ít nhất chốt lại bằng một cập nhật có thể truy vết.
Chỉ cần giữ kỷ luật này trong vài sprint, đội sẽ thấy review nhanh hơn và ít cảm giác “bị bắt bẻ” hơn, vì mọi góp ý đều quay về một chuẩn đã được thống nhất.
Lỗi phối hợp thường gặp khi đội vẫn làm theo thói quen cũ
- BA chưa khóa yêu cầu nhưng developer đã code, đến lúc review mới phát hiện mỗi người hiểu một kiểu.
- Tech Lead nói miệng về contract nhưng không ghi lại, reviewer và developer nhớ khác nhau.
- Reviewer dùng gu cá nhân để chặn merge dù thay đổi vẫn đúng brief và đúng contract.
- Developer tự ý mở rộng phạm vi vì nghĩ “tiện tay sửa luôn”, làm mất traceability.
- PM chen trực tiếp vào review để ép merge nhanh, khiến lỗi trách nhiệm bị che đi thay vì được xử lý đúng chỗ.
Những lỗi này không phải lỗi của riêng công cụ nào. Chúng đến từ việc vai trò không được phân định rõ và mọi người vẫn cộng tác theo thói quen cũ.
Kết luận
Khi reviewer nên reject, khi nào nên request change và khi nào nên cho merge không phải là câu hỏi về tính cách reviewer, mà là câu hỏi về kỷ luật cộng tác của đội. Midi Coder cho thấy một hướng tiếp cận rõ ràng: giữ con người trong vòng lặp, nhưng phân vai minh bạch hơn bằng brief, contract, version và traceability. Khi BA khóa đúng yêu cầu, Tech Lead khóa đúng contract, Developer triển khai đúng phạm vi và reviewer kiểm tra theo chuẩn đã chốt, quyết định review sẽ nhất quán hơn, nhanh hơn và công bằng hơn. Thành công cuối cùng không nằm ở công cụ đơn lẻ, mà ở việc cả đội có thực sự làm việc có kỷ luật với nhau hay không.
