Best practices cho backend developer bắt đầu từ review nghiêm túc
Một trong những best practices cho backend developer mà chúng tôi luôn nhắc đội ngũ mới là đừng bao giờ coi code review chỉ là thủ tục ký duyệt cho xong. Chúng tôi từng chứng kiến nhiều dự án nơi reviewer chỉ lướt qua vài dòng code. Thấy chạy được, thấy tên biến ổn là duyệt luôn. Bug logic ẩn sâu bên trong vẫn lọt qua. Nó âm thầm nằm chờ đến khi người dùng thật gặp phải mới lộ ra.
Ở bên mình, có một lần đội dev merge tính năng thanh toán chỉ sau năm phút review. Reviewer chỉ kiểm tra format, không hỏi gì về trường hợp số tiền âm hay sai đơn vị tiền tệ. Vài ngày sau, hệ thống ghi nhận một giao dịch bị trừ tiền hai lần vì thiếu điều kiện kiểm tra trạng thái transaction. Chúng tôi phải rollback gấp và giải trình với khách hàng. Đó là bài học nhớ đời cho cả team.
Review qua loa không chỉ gây ra bug tức thời. Nó còn tạo ra một văn hoá xấu trong đội ngũ. Khi mọi người quen với việc duyệt code nhanh cho kịp deadline, review dần trở thành bước hình thức. Nó không còn là lớp bảo vệ thực sự trước khi code chạm vào production nữa.
Những điểm cần soi kỹ khi review logic backend
Ưu tiên đọc logic xử lý lỗi và ràng buộc dữ liệu trước khi để ý đến chuyện format hay đặt tên biến. Đây là nguyên tắc đầu tiên trong danh sách best practices cho backend developer mà chúng tôi áp dụng ở mọi dự án mình từng tham gia. Một hàm xử lý input có bắt đủ trường hợp dữ liệu null, chuỗi rỗng, hay số âm hay chưa. Đó mới là câu hỏi cần đặt ra trước tiên, thay vì chăm chăm vào dấu chấm phẩy.
Chúng tôi hay khuyên reviewer tự hỏi: trường hợp nào đoạn code này sẽ fail. Nếu không trả lời được câu hỏi đó một cách chắc chắn, nghĩa là phần logic chưa đủ chặt. Cách tiếp cận này giúp phát hiện sớm những lỗ hổng mà test case thông thường hay bỏ sót. Đặc biệt là các nhánh xử lý ngoại lệ hiếm khi được viết test tự động đầy đủ.
Nếu bạn muốn tìm hiểu sâu hơn về cách tổ chức tầng xử lý dữ liệu sao cho ổn định, đội ngũ chúng tôi từng phân tích khá kỹ trong bài cách thiết kế API layer để dữ liệu chạy mượt. Bài đó giúp bạn có thêm tiêu chí khi đánh giá phần validate dữ liệu trong lúc review.
Tác vụ chạy nền và xử lý bất đồng bộ dễ bị bỏ sót
Một mảng khác mà chúng tôi thấy hay bị review sơ sài là các tác vụ chạy nền, job xử lý bất đồng bộ. Những đoạn code này thường không lỗi ngay khi chạy test thủ công. Nhưng chúng lại âm thầm gây race condition hoặc duplicate task khi chạy thật với traffic lớn.
Có dự án đội ngũ từng tham gia dùng queue để gửi email xác nhận đơn hàng. Review ban đầu không phát hiện ra rằng nếu worker restart giữa chừng, message có thể bị xử lý lại từ đầu. Kết quả là khách hàng nhận ba, bốn email trùng lặp cho cùng một đơn hàng. Nếu bạn quan tâm đến cách thiết kế job định kỳ và webhook an toàn hơn, có thể đọc thêm thiết kế webhook và job định kỳ cho phần mềm tích hợp AI tự động hoá quy trình mà chúng tôi từng viết, khá liên quan đến tình huống này.
Ngoài bài đó, bạn cũng có thể ghé trang chủ của chúng tôi để xem thêm nhiều bài viết khác về backend và .NET mà đội ngũ đã tổng hợp theo thời gian.
Dấu hiệu nên yêu cầu viết lại thay vì chỉ sửa nhỏ
Một đoạn code chứa quá nhiều nhánh if-else lồng nhau, đọc muốn hoa mắt, thường là dấu hiệu nên yêu cầu viết lại. Vá thêm một điều kiện lên trên một cấu trúc đã rối chỉ khiến vấn đề phức tạp hơn về sau.
Chúng tôi từng gặp một hàm xử lý đơn hàng dài hơn hai trăm dòng. Nó gộp cả logic tính giá, kiểm tra tồn kho, gửi thông báo và ghi log vào cùng một chỗ. Sửa một chỗ nhỏ trong hàm đó có nguy cơ làm hỏng ba chức năng khác cùng lúc. Lúc này, tách nhỏ hàm theo từng trách nhiệm riêng biệt là lựa chọn đúng đắn hơn nhiều so với việc cố vá thêm.
Sau lần đó, đội ngũ chúng tôi quyết định tách lại toàn bộ luồng xử lý đơn hàng thành các service nhỏ, mỗi service chỉ lo một việc. Code review từ đó cũng nhẹ nhàng hơn hẳn, vì reviewer chỉ cần tập trung vào đúng phần logic liên quan thay vì đọc lại cả trăm dòng mỗi lần có thay đổi nhỏ.
Checklist nhanh cho backend developer khi mới nhận việc review
- Kiểm tra logic xử lý lỗi đã bao quát đủ các trường hợp bất thường hay chưa, kể cả những case hiếm khi xảy ra
- Xác nhận dữ liệu đầu vào được validate trước khi đi vào phần xử lý nghiệp vụ chính
- Xem các tác vụ chạy nền, job bất đồng bộ có được xử lý an toàn khi hệ thống restart hoặc gặp lỗi mạng
- Đánh giá xem một hàm có đang ôm quá nhiều trách nhiệm cùng lúc hay không
- Luôn đặt câu hỏi đoạn code này sẽ fail trong trường hợp nào trước khi bấm approve
Áp dụng checklist này một cách đều đặn giúp backend developer mới hình thành thói quen kiểm tra kỹ, dù đang trong giai đoạn làm quen dự án. Nếu bạn đang chuẩn bị bộ tiêu chí đánh giá kỹ thuật rộng hơn, ngoài phạm vi code review nội bộ, có thể tham khảo thêm checklist kỹ thuật khi chọn công ty ứng dụng AI cho dự án công nghệ mà chúng tôi từng viết. Cách xây dựng checklist ở đó cũng áp dụng được khá tốt cho việc review code hằng ngày.
Giữ tinh thần xây dựng khi để lại comment review
Ngoài phần kỹ thuật, thái độ khi để lại comment cũng quan trọng không kém. Mục tiêu cuối cùng của review là nâng chất lượng chung của sản phẩm, không phải để chỉ trích người viết code. Chúng tôi luôn nhắc reviewer trong team dành vài dòng giải thích lý do đằng sau mỗi góp ý, thay vì chỉ ném ra một câu yêu cầu sửa khô khan.
Cách làm này giúp người viết code hiểu sâu vấn đề hơn, tránh lặp lại lỗi tương tự ở những commit sau. Về lâu dài, nó cũng giúp cả đội backend nâng cao năng lực chung, chứ không chỉ dừng lại ở việc bắt lỗi từng dòng code riêng lẻ. Đó cũng là lý do chúng tôi vẫn xem review nghiêm túc là một trong những best practices cho backend developer đáng đầu tư công sức nhất, dù đôi khi nó khiến quy trình chậm lại vài giờ so với việc duyệt qua loa cho xong.
