Nói đến Agile, pair programming hay code review, nhiều người nghĩ ngay đến giáo trình, quy trình, lý thuyết. Nhưng trong thực tế, những khái niệm này vận hành khác xa sách vở. Có team làm rất chỉn chu, có team chỉ “dán nhãn” Agile cho có. Có kỹ sư được review code hàng ngày, có nơi thì chỉ “merge nhanh cho kịp sprint”.
Vậy khi bạn đã là một senior developer trở lên, bạn cần hiểu rõ thực tế trong doanh nghiệp diễn ra thế nào, để không bị động hoặc “vỡ mộng” khi tham gia team mới, đồng thời biết cách thích nghi và cải tiến.
1. Pair programming trong thực tế
Định nghĩa ngắn gọn
Pair programming là một kỹ thuật phát triển phần mềm mà hai lập trình viên cùng làm việc trên cùng một máy, giải quyết cùng một task. Một người “lái chính” (driver), người còn lại “hướng dẫn” (navigator).
Khi nào các công ty thực sự dùng pair programming?
- Trong onboarding kỹ sư mới, giúp họ hiểu kiến trúc, convention, hệ thống.
- Khi xử lý task có logic phức tạp, cần phối hợp nhiều module.
- Khi làm production hotfix, cần đảm bảo code đúng ngay từ lần đầu.
- Trong môi trường DevOps/SRE, debugging issue real-time với production log.
- Một số công ty (ví dụ ThoughtWorks) làm pair programming full-time như triết lý phát triển.
Lợi ích thực tế (khi làm đúng)
- Giảm bug: nhiều lỗi được phát hiện sớm hơn.
- Lan truyền kiến thức nội bộ: junior học nhanh, senior củng cố.
- Tăng chất lượng giao tiếp kỹ thuật trong team.
- Giúp team align về cách giải quyết vấn đề.
Những khó khăn thường gặp
- Tốn tài nguyên: 2 người làm 1 việc, hiệu suất ban đầu có thể thấp.
- Chênh lệch trình độ: dễ xảy ra tình huống “senior code, junior ngồi gật”.
- Không khí ngại ngùng: nếu không có văn hoá phản biện, dễ bị gượng ép.
- Không phù hợp với mọi người: introvert, hoặc người tập trung sâu thường khó chịu.
Làm sao để pair programming hiệu quả?
- Xác định mục tiêu rõ ràng: code review? mentor? xử lý bug?
- Ghi lại quyết định kỹ thuật trong quá trình làm để không bị trôi mất.
- Luân phiên role (driver <-> navigator) sau mỗi 30–45 phút.
- Dùng tool hỗ trợ từ xa như:
- Tuple: https://tuple.app
- Visual Studio Live Share: https://visualstudio.microsoft.com/services/live-share/
2. Code review: từ hình thức đến chất lượng
Mục tiêu thực sự của code review
Không chỉ là “check syntax đúng chưa”, mà để đảm bảo:
- Code tuân thủ chuẩn (convention, coding style)
- Giải pháp phù hợp về mặt kiến trúc
- Hiểu rõ impact khi merge: performance, security, maintainability
- Truyền đạt kiến thức & kinh nghiệm
Quy trình code review ở các công ty có tổ chức
- Dev mở pull request (PR) trên GitHub/GitLab/Bitbucket
- Gắn reviewer (thường là 1–2 người)
- Reviewer check code + bối cảnh business
- Đưa comment, yêu cầu sửa nếu cần
- Chủ PR cập nhật, push lại, reviewer approve
- Merge vào nhánh chính
Tùy công ty, quy trình có thể khác biệt. Có nơi yêu cầu CI/CD phải pass, có nơi còn cần approval từ QA hoặc PO.
Một PR tốt thường có gì?
- Description rõ ràng: “Giải quyết issue gì, theo hướng nào”
- Dễ review: chia nhỏ commit, logic từng phần rõ ràng
- Có test kèm theo nếu liên quan đến logic/phân nhánh xử lý
- Không thay đổi không cần thiết (ví dụ đổi indent hoặc đổi tên biến không liên quan)
Code review hiệu quả: văn hóa quan trọng hơn quy trình
- Đừng phê phán cá nhân, hãy nói về giải pháp: “đoạn này có thể gây memory leak vì…”
- Review kỹ những phần ảnh hưởng đến security, logic xử lý tiền, quyền truy cập
- Reviewer cũng học được từ PR của người khác – giúp phát hiện cách tiếp cận mới
- Người viết PR không nên nghĩ mình bị kiểm tra, mà là đang làm việc nhóm
Tài liệu tham khảo:
- Google’s Code Review Guidelines: https://google.github.io/eng-practices/review/
3. Agile: sự khác biệt giữa lý thuyết và thực tế
Agile không phải là Scrum, và Scrum không phải là Jira
Agile là tư duy, không phải công cụ. Rất nhiều công ty đang làm Scrum máy móc (standup – backlog – sprint – retro) nhưng đội ngũ vẫn chậm chạp, không học hỏi.
Các framework Agile thường gặp:
- Scrum: có Sprint, Backlog, PO, Scrum Master. Phù hợp với team vừa & nhỏ, phát triển sản phẩm lặp.
- Kanban: không chia sprint, linh hoạt hơn. Phù hợp với nhóm xử lý task liên tục, như DevOps.
- XP (Extreme Programming): tập trung kỹ thuật (TDD, CI, pair programming). Thường thấy trong team chất lượng cao.
Thực tế Agile trong công ty
| Lý thuyết | Thực tế thường thấy |
| Daily stand-up hiệu quả | Nói “hôm qua làm cái này, hôm nay tiếp tục” cho có |
| PO hiểu nhu cầu người dùng | PO ép dev làm đúng ý mình, không nghe feedback dev |
| Retrospective cải tiến | Retro tổ chức lấy lệ, không ai hành động sau buổi họp |
| Sprint kế hoạch chuẩn | Sprint vừa bắt đầu đã bị task phát sinh |
| Dev tự chủ & cross-functional | Dev bị ép theo deadline, không được nói không |
Khi nào Agile thực sự hiệu quả?
- Khi đội ngũ có quyền tự chủ và trách nhiệm cao
- Khi product thực sự thay đổi nhanh và cần feedback liên tục
- Khi dev được lắng nghe, không chỉ là người code theo đặc tả
- Khi công ty hiểu Agile là văn hoá làm việc, chứ không phải công cụ báo cáo
4. Gợi ý cho kỹ sư senior muốn nâng cao
Nếu bạn là senior developer:
- Chủ động đề xuất pair programming khi onboarding hoặc debug khó
- Review kỹ các pull request có logic quan trọng, đừng “LGTM” cho có
- Khi làm Agile: phản biện đúng chỗ – đặt câu hỏi tại sao phải làm task A? Có hướng khác không?
- Dẫn dắt junior hiểu ý nghĩa thật sự của code review – training qua PR là cách học hiệu quả nhất
- Góp phần cải thiện quy trình: tự động hoá check convention, refactor template PR, cải tiến ticket grooming
Một số team điển hình có áp dụng hiệu quả:
- Spotify Squad Model: https://engineering.atspotify.com/2020/05/spotify-engineering-model/
- Basecamp’s Shape Up: https://basecamp.com/shapeup
- Atlassian’s Agile Practices: https://www.atlassian.com/agile
Đằng sau các thuật ngữ “xịn” như Agile, pair programming, code review là câu chuyện rất thực tế về cách con người phối hợp với nhau trong môi trường làm sản phẩm.
Bạn không cần quá lý tưởng hóa, nhưng cần hiểu đúng bản chất để không bị rơi vào cái bẫy của “hành xác quy trình”. Là senior, bạn là người định hình văn hóa kỹ thuật và ảnh hưởng đến cách làm việc lâu dài của team.
Khám phá cơ hội công việc phù hợp với kỹ sư phần mềm tư duy hệ thống, làm việc hiệu quả và thực chiến tại: https://itworks.asia
