Nỗi khổ khi PR bị “bỏ rơi” hoặc review sai chuyên môn
Nếu đang làm việc trong team từ 5-10 người, chắc hẳn bạn đã từng rơi vào cảnh: Tạo một Pull Request (PR) cực kỳ tâm huyết nhưng chờ mãi chẳng ai ngó ngàng. Bạn gửi link vào group chat, chờ một tiếng, hai tiếng, rồi cả ngày trôi qua vẫn im lìm. Hoặc tệ hơn, một bạn chuyên Frontend lại vào review logic Backend, dẫn đến những góp ý không thực sự sát sao.
Gốc rễ của vấn đề là sự mập mờ trong “quyền sở hữu code” (Code Ownership). Khi ai cũng có quyền review mọi thứ, kết quả thường là chẳng ai thấy mình có trách nhiệm phải làm cả. Hệ quả? Tốc độ release bị kéo lùi, còn chất lượng code thì hên xui.
Kinh nghiệm thực tế từ một dự án outsource mình từng tham gia: Một bạn Junior lỡ tay sửa nhầm file docker-compose.yml của team DevOps. Do thiếu cơ chế chặn, PR được một bạn Junior khác approve và merge thẳng vào nhánh chính. Kết quả là CI/CD sập, cả team mất trắng một buổi chiều để trace lỗi. Sau cú phốt đó, mình nhận ra CODEOWNERS không còn là tùy chọn, mà là bắt buộc để bảo vệ hệ thống.
CODEOWNERS là gì?
Hãy coi CODEOWNERS là một bản “phân vai” trong repository. Đây là một file cấu hình đơn giản nằm trong repo (GitHub/GitLab) giúp định nghĩa chính xác ai hoặc team nào chịu trách nhiệm cho từng phần code cụ thể.
Ngay khi bạn thay đổi một file có tên trong danh sách, hệ thống sẽ tự động gán những người đó làm Reviewers. Bạn không cần phải nhớ xem file này do ai viết, hay phải tag tên thủ công như trước nữa.
Ba lợi ích sát sườn nhất bao gồm:
- Tự động hóa hoàn toàn: Tiết kiệm khoảng 5-10 phút chờ đợi và tag người cho mỗi PR.
- Đúng người đúng việc: Code Database sẽ do DBA duyệt, CSS sẽ do UI/UX expert phụ trách.
- Bảo mật tối đa: Các file nhạy cảm như
/securityhay/configluôn được giám sát bởi những người dày dạn kinh nghiệm nhất.
Cách thiết lập CODEOWNERS chi tiết
Cả GitHub và GitLab đều hỗ trợ file này với cú pháp tương đồng, chỉ khác biệt một chút về vị trí đặt file.
1. Vị trí đặt file
Bạn có thể đặt file CODEOWNERS (không có phần mở rộng) ở các đường dẫn sau:
- Thư mục gốc:
/CODEOWNERS - Thư mục ẩn:
.github/CODEOWNERShoặc.gitlab/CODEOWNERS
Mình luôn ưu tiên đặt trong thư mục .github/ hoặc .gitlab/. Cách này giúp thư mục gốc của project gọn gàng hơn.
2. Cú pháp viết file
Cú pháp của CODEOWNERS rất giống với .gitignore. Bạn chỉ cần xác định đường dẫn file, sau đó là username của người chịu trách nhiệm.
# Gán mặc định cho tất cả file trong repo
* @tech-lead-username
# Team Frontend phụ trách toàn bộ file .js
*.js @org-name/frontend-team
# Chỉ định cụ thể cho một thư mục tài liệu
/docs/ @documentation-expert
# File cấu hình hạ tầng chỉ DevOps được duyệt
/infra/terraform/ @devops-seniorQuy tắc vàng: Thứ tự trong file cực kỳ quan trọng. Những dòng viết dưới cùng sẽ có độ ưu tiên cao nhất (override các quy tắc phía trên).
Áp dụng thực tế cho dự án Fullstack
Giả sử team bạn đang vận hành một ứng dụng Web. Để tránh việc “ai cũng có thể sửa mọi thứ”, file CODEOWNERS nên được phân rã như sau:
# 1. Tech Lead giám sát toàn bộ hệ thống
* @big-boss
# 2. Phân quyền cho Backend
/src/api/ @backend-team
# 3. Phân quyền cho Frontend
/src/components/ @frontend-team
/src/styles/ @frontend-team
# 4. Bảo vệ hạ tầng và CI/CD
.github/workflows/ @devops-engineer
Dockerfile @devops-engineerKhi một bạn Frontend sửa file trong /src/components/, GitHub sẽ tự gán @frontend-team vào PR. Nếu bạn đó “tiện tay” sửa luôn Dockerfile, @devops-engineer sẽ bị hệ thống gọi tên ngay lập tức.
Kết hợp Protected Branches để tăng tính kỷ luật
Nếu chỉ tạo file CODEOWNERS, nó mới dừng lại ở mức gợi ý. Để biến nó thành một rào chắn thực thụ, bạn cần bật Branch Protection Rules.
Trên GitHub, bạn vào Settings > Branches, chọn nhánh chính và tích vào Require review from Code Owners. Khi đó, PR không thể merge nếu thiếu chữ ký từ đúng “chủ xị” được chỉ định. Dù bạn có nhận được hàng chục approve từ người khác, hệ thống vẫn sẽ chặn lại cho đến khi đúng người có thẩm quyền đồng ý.
Những lưu ý “xương máu”
Trong quá trình triển khai cho nhiều dự án, mình rút ra 3 bài học để tránh gây phiền hà cho team:
- Tránh quá đông người làm chủ một file: Nếu một file có 5 người cùng quản lý, tâm lý “chắc người kia review rồi” sẽ xuất hiện. Tốt nhất chỉ nên gán cho 1-2 người hoặc 1 team nhỏ.
- Cập nhật nhân sự kịp thời: Hãy sửa file
CODEOWNERSngay khi có người nghỉ việc. Đừng để PR bị treo chỉ vì người review duy nhất đã rời công ty từ tháng trước. - Đừng biến Tech Lead thành nút thắt: Tránh gán
* @tech-leadcho mọi file nếu team lớn. Tech Lead sẽ bị ngập trong thông báo và trở thành bottleneck của cả dự án.
Áp dụng CODEOWNERS là bước đi quan trọng để chuyên nghiệp hóa quy trình. Nó không chỉ là công cụ, mà còn giúp định hình văn hóa trách nhiệm trong team. Hãy thử thiết lập ngay hôm nay, bạn sẽ thấy sự khác biệt về tốc độ và chất lượng code chỉ sau một tuần.
