Tư Duy Nhận Task "Chuẩn Chỉnh" Cho Fresher Tập 4: "Kiểm Tra Kép" (Tư duy nghiệm thu sản phẩm).

Đây là giai đoạn quyết định xem Fresher sẽ được đánh giá là một "Kỹ sư đáng tin cậy" hay chỉ là một "Thợ gõ code cẩu thả". Bệnh rất phổ biến của người mới là vừa gõ xong dòng code cuối cùng, thấy chạy được luồng chính (Happy Path) là lập tức ném sang cho Mentor review hoặc đẩy sang cho QA test.

Dưới đây là cách rèn luyện tư duy tự nghiệm thu (Self-QC) cho Fresher trước khi bàn giao task.

1. Đối chiếu "Bản hợp đồng" (Verify Requirements)

Đừng vội mừng khi code chạy không báo lỗi. Hệ thống chạy mượt nhưng sai logic nghiệp vụ thì vẫn là một sản phẩm vứt đi.

• Tư duy cốt lõi: Làm đúng yêu cầu quan trọng hơn làm những thứ màu mè phức tạp.
• Hành động cần làm: Mở lại file note hoặc đoạn chat xác nhận yêu cầu ở Tập 1. Gạch chéo từng đầu mục đã hoàn thành.
  • API đã đúng method (GET/POST/PUT) và HTTP Status Code chuẩn RESTful chưa?
  • Response trả về có đúng format JSON đã thống nhất với team Frontend/Mobile chưa?
  • Đã viết đủ document cho API (Swagger/Postman) để người khác đọc hiểu cách dùng chưa?

2. Tư duy của Kẻ phá hoại (Test Edge Cases & Unhappy Paths)

Fresher thường chỉ test dữ liệu đẹp, nhập đúng định dạng và hài lòng với kết quả. Nhưng thực tế, user và các hệ thống khác sẽ ném vào API đủ thứ rác rưởi.

• Tư duy cốt lõi: Đừng để người khác tìm thấy lỗi cơ bản trong code của mình. Hãy tự phá hệ thống trước khi nó bị phá thực sự.
• Hành động cần làm: Tự đặt ra các kịch bản hóc búa để test.
  • Dữ liệu rỗng hoặc sai kiểu: Chuyện gì xảy ra nếu field user_id truyền lên là string thay vì integer? Xử lý validate đã chặt chẽ và trả về lỗi rõ ràng chưa?
  • Nghiệp lệ Database (Database Exceptions): Nếu đang chạy transaction mà một lệnh insert/update bị lỗi, data có được rollback sạch sẽ không, hay bị treo một nửa?
  • Bài toán Concurrency (Đồng thời): Nếu 100 request đập vào cùng 1 mili-giây để tranh nhau mua 1 vé cuối cùng, hệ thống có bị race condition bán vượt quá số vé không? Đã áp dụng các biện pháp khóa (Pessimistic/Optimistic lock) hoặc dùng Redis để chặn chưa?

3. Review lại chính mình (Clean Code & Refactor)

Trước khi tạo Pull Request (PR), Fresher phải tự đóng vai một người khó tính để soi lại từng dòng code của mình. Đừng để Mentor mất thời gian comment những lỗi vụn vặt.

• Tư duy cốt lõi: Code viết ra không chỉ để máy đọc, mà còn để con người (đồng nghiệp) đọc và bảo trì sau này.
• Hành động cần làm (Self-Review Checklist):
  • Dọn dẹp "Rác": Xóa ngay những dòng console.log, fmt.Println, var_dump, các đoạn code bị comment out (mờ đi) không còn sử dụng.
  • Kiểm tra Hardcode: Tuyệt đối không hardcode các thông tin nhạy cảm (token, password, URL) trực tiếp vào code. Phải đưa vào file biến môi trường (.env).
  • Tuân thủ Kiến trúc: Đảm bảo không phá vỡ Clean Architecture. Logic tính toán nghiệp vụ (Business logic) tuyệt đối không được viết lẫn lộn trong Controller, mà phải được tách bạch xuống lớp Usecase/Service; query database phải đưa xuống Repository.

Red Flags (Dấu hiệu cảnh báo nguy hiểm) cần chấn chỉnh nghiêm khắc:

• "Hôm qua máy em chạy được mà": Lỗi kinh điển khi môi trường dev local của Fresher chạy mượt nhưng đẩy lên server (Staging) thì sập vì thiếu file config, thiếu thư viện hoặc chưa chạy file migrate database. Bắt buộc phải test lại trên môi trường Staging.
• Giao task với một cục code bẩn: Tên biến đặt vô nghĩa (var a, var b1), file dài hàng nghìn dòng không chia hàm con, lùi lề thò thụt lung tung.