Laravel

© 2026 Laravel

Quay lại

Mục lục bài viết

  1. Người mới bắt đầu (Beginner)
  2. Trung cấp (Intermediate)
  3. Nâng cao (Advanced)
  4. Kiến trúc sư (Architect)
  5. Tình huống thực tế (Practical Scenarios)
  6. Nên biết
  7. Lưu ý

Sử dụng các mục để điều hướng nhanh

Code Review & Engineering Practices: Quy trình Kỹ thuật Chuẩn

Ngày đăng 17/04/2026

#Người mới bắt đầu (Beginner)

Q1: Git là gì? Tại sao cần dùng Git?

Trả lời: Hệ thống quản lý phiên bản phân tán. Giúp lưu lại lịch sử thay đổi code, làm việc nhóm không bị ghi đè dữ liệu của nhau và dễ dàng quay lại các bản cũ khi có lỗi.

Q2: Pull Request (PR) hoặc Merge Request (MR) là gì?

Trả lời: Lời yêu cầu merge code từ nhánh của bạn vào nhánh chung. Đây là nơi diễn ra các thảo luận và review code trước khi thay đổi chính thức được chấp nhận.

Q3: Tại sao tin nhắn commit (Commit Message) lại quan trọng?

Trả lời: Giúp đồng nghiệp (và chính bạn sau này) hiểu nhanh thay đổi này làm gì mà không cần đọc từng dòng code. Một commit message tốt giúp việc debug và tạo changelog dễ dàng hơn.

Q4: Quy trình Git cơ bản: clone, add, commit, push, pull.

Trả lời:

  • clone: Tải code về máy.
  • add: Chọn các thay đổi chuẩn bị lưu.
  • commit: Lưu các thay đổi kèm mô tả.
  • push: Đẩy code lên server.
  • pull: Tải các thay đổi mới nhất từ server về.

#Trung cấp (Intermediate)

Q1: Giải thích mô hình "GitFlow".

Trả lời: Mô hình quản lý nhánh gồm: master (prod), develop (dev), feature/ (tính năng mới), release/ (chuẩn bị prod), và hotfix/ (sửa lỗi gấp trên prod).

Q2: Bạn nên kiểm tra những gì khi Review code của đồng nghiệp?

Trả lời:

  1. Logic có đúng yêu cầu không? 2. Có lỗ hổng bảo mật không? 3. Hiệu năng có vấn đề không (N+1 query)? 4. Code có dễ đọc/clean không? 5. Đã có Unit Test chưa?
Q3: Phân biệt `git merge` và `git rebase`.

Trả lời:

  • merge: Gộp nhánh, tạo ra một commit gộp (merge commit), giữ nguyên lịch sử rẽ nhánh.
  • rebase: Đưa các commit của nhánh mình lên trên cùng của nhánh đích, tạo ra lịch sử dạng đường thẳng sạch sẽ nhưng làm thay đổi mã hash của commit cũ.
Q4: Tiêu chuẩn "Conventional Commits" là gì?

Trả lời: Quy tắc đặt tên commit: <type>(scope): <description>. Ví dụ: feat(auth): add google login, fix(api): handle null response.

Q5: "Trunk-based Development" khác gì GitFlow?

Trả lời: Mọi người cùng làm việc trên 1 nhánh chính (main/trunk). Commit nhỏ, thường xuyên merge và dùng Feature Flags để ẩn tính năng chưa xong. Giúp CI/CD nhanh hơn GitFlow.

#Nâng cao (Advanced)

Q1: Cách xử lý xung đột (Merge Conflicts) phức tạp trong team lớn.

Xử lý: 1. Luôn pull code mới nhất trước khi làm. 2. Chia nhỏ PR để giảm phạm vi xung đột. 3. Sử dụng các công cụ so sánh (Diff tools). 4. Liên lạc trực tiếp với người viết đoạn code gây xung đột để hiểu ý đồ trước khi sửa.

Q2: Làm thế nào để duy trì văn hóa Review tích cực?

Trả lời: Dùng cấu trúc: “Tôi thấy… vì vậy tôi đề nghị…” thay vì “Bạn làm sai rồi”. Khen ngợi những đoạn code hay. Review nhanh (trong vòng 24h) để không làm nghẽn tiến độ.

Q3: Giải thích về "Pre-commit Hooks".

Trả lời: Các script tự động chạy trên máy dev trước khi commit (ví dụ: tự động chạy linter, check style, chạy unit test). Giúp ngăn chặn code “bẩn” đẩy lên server.

Q4: Chiến lược "Automated Code Review" dùng công cụ nào?

Trả lời: Sử dụng SonarQube, Scrutinizer, hoặc Github Actions kết hợp với PHPStan/Psalm để tự động phát hiện lỗi logic và bảo mật ngay khi mở PR.

#Kiến trúc sư (Architect)

Q1: Thiết kế quy trình CI/CD đảm bảo 0% lỗi logic lọt lên Production.

Trả lời: Lắp đặt các chốt chặn: 1. Lint/Style check. 2. Static Analysis. 3. Unit/Integration Tests. 4. QA Manual test trên môi trường Staging. 5. Canary Deployment (chạy thử trên 5% user).

Q2: Tầm nhìn: "Code Review as a Knowledge Sharing Tool".

Trả lời: Review không chỉ là bắt lỗi, mà là cách Senior dạy Junior và ngược lại. Architect cần đảm bảo Review là quá trình học hỏi lẫn nhau, giúp nâng tầm trình độ chung của cả team.

#Tình huống thực tế (Practical Scenarios)

S1: PR của bạn có 50 file thay đổi và bị đồng nghiệp từ chối review vì quá lớn. Bạn làm gì?

Xử lý: 1. Xin lỗi team. 2. Tách nhỏ PR đó ra thành 3-4 PR nhỏ hơn, mỗi cái giải quyết 1 phần logic độc lập. 3. Lần sau tuân thủ nguyên tắc “Atomic PR”.

S2: Có tranh cãi nảy lửa về cách đặt tên biến trong PR. Bạn xử lý thế nào?

Xử lý: 1. Tham chiếu tới Coding Standard của team. 2. Nếu không có, hãy chọn cách đơn giản nhất và kết thúc tranh cãi nhanh để làm việc khác. 3. Đưa vấn đề vào buổi họp team để thống nhất tiêu chuẩn chung sau này.

#Nên biết

  • Các lệnh Git nâng cao: cherry-pick, stash, revert, reset.
  • Cách viết một PR Description đầy đủ (Yêu cầu là gì? Đã làm gì? Ảnh minh chứng).

#Lưu ý

  • Review hời hợt chỉ để merge nhanh.
  • Commit những file không cần thiết (vendor/, .env, node_modules/).
  • Để PR quá lâu không merge dẫn đến xung đột chồng chất.
Chủ đề:
#code-review #git #workflow #engineering #practices

Bài viết liên quan

Tiếp tục hành trình nâng tầm kiến thức của bạn