Tư Duy Nhận Task "Chuẩn Chỉnh" Cho Fresher Tập 5: "Hậu Phẫu" (Đón nhận Feedback).

Tạo xong Pull Request (PR) không có nghĩa là task đã xong. Trận chiến thực sự để biến một Fresher non nớt thành một Software Engineer cứng cáp nằm ở màn Code Review. Đối mặt với những dòng comment đỏ chót của Mentor/Senior là lúc cái tôi (ego) của Fresher dễ bị tổn thương nhất.

Dưới đây là cách setup tư duy để Fresher biến những lời chê bai thành kinh nghiệm thực chiến.

1. Phân tách "Code" và "Cá nhân" (Ego Management)

Khi nhìn thấy 20 cái comments chê code chạy chậm, logic cồng kềnh, Fresher rất dễ rơi vào trạng thái phòng thủ, tự ái và cho rằng sếp đang ghét mình.

• Tư duy cốt lõi: Người ta review dòng code của bạn, chứ không đánh giá nhân cách hay giá trị con người bạn. Code ngu không có nghĩa là bạn dốt, nó chỉ có nghĩa là bạn chưa biết.
• Hành động cần làm:
  • Đọc comment với một cái đầu lạnh. Nếu Mentor viết: "Đoạn này truy vấn vòng lặp sinh ra lỗi N+1 query, làm sập database mất", hãy tập trung vào từ khóa "N+1 query" để tìm cách fix (sử dụng eager loading hoặc join), thay vì ngồi buồn bã vì bị chê.
  • Tuyệt đối không dùng những câu ngụy biện mang tính cá nhân như: "Nhưng em đã cố gắng hết sức mất 3 ngày rưỡi rồi". Hệ thống không quan tâm bạn thức bao nhiêu đêm, nó chỉ quan tâm code có tối ưu không.

2. Kỹ năng Hồi đáp Feedback (Resolve Comments)

Nhiều bạn Fresher xử lý feedback theo kiểu "chữa cháy": Sếp bảo sửa dòng 45 thì vào sửa đúng dòng 45 cho xong chuyện, không thèm nhìn tổng thể.

• Tư duy cốt lõi: Quá trình Code Review là một cuộc tranh luận kỹ thuật 2 chiều, không phải là nhận thánh chỉ.
• Hành động cần làm:
  • Đồng ý và Sửa (Acknowledge): Nếu Mentor đúng, hãy fix code và reply ngắn gọn (VD: "Done. Em đã đổi từ truyền tham trị (pass-by-value) sang con trỏ (pointer) để tối ưu memory").
  • Hỏi lại để đào sâu (Probe): Nếu không hiểu tại sao lại phải sửa, HÃY HỎI. (VD: "Anh ơi, tại sao chỗ này mình nên dùng Redis Hash thay vì String thông thường ạ? Anh giải thích thêm giúp em được không?").
  • Phản biện có cơ sở (Push back): Nếu bạn có lý do chính đáng cho cách code của mình, hãy giải thích bằng kỹ thuật, đừng im lặng sửa. (VD: "Em cố tình không đánh Index cột này vì tần suất update của nó quá cao, nếu đánh Index sẽ làm chậm quá trình ghi. Anh xem luồng này mình ưu tiên Đọc hay Ghi ạ?").

3. Sổ tay "Bản ngã" (Retrospective & Lưu trữ kinh nghiệm)

Nếu tháng này bị chửi vì quên check null, tháng sau vẫn bị chửi vì nguyên nhân đó, thì lỗi không còn ở sự thiếu kinh nghiệm nữa, mà là thái độ làm việc hời hợt.

• Tư duy cốt lõi: Mắc lỗi mới là tiến bộ. Mắc lại lỗi cũ là sự thụt lùi.
• Hành động cần làm:
  • Lập một file note cá nhân (hoặc trang Notion) mang tên "Những vết sẹo".
  • Mỗi lần được review xong, tổng hợp lại các bài học lớn. (Ví dụ: "1. Luôn set TTL (thời gian sống) khi lưu key vào Redis. 2. Không bao giờ viết logic business trong Controller. 3. Nhớ viết rollback transaction nếu query bị lỗi.").
  • Mở sổ tay này ra check lại 1 lượt TRƯỚC KHI nộp Pull Request cho các task tiếp theo.

🛑 Red Flags (Những hành vi "tự hủy" trên bàn Code Review)

• Cãi cùn (Defensive): Luôn tìm cách bao biện: "Chỗ này em code tạm cho chạy được thôi, tính mai sửa", "Do framework nó bắt thế chứ không phải tại em".
• Lén lút "Resolve conversation": Mentor comment chỉ ra lỗi, không thèm sửa code nhưng lại tự ý bấm nút "Resolve/Done" trên Git để giấu đi nhằm vượt ải merge code. Đây là tối kỵ về mặt đạo đức nghề nghiệp.
• Tự ái lặn mất tăm: Nhận feedback xong dỗi, mất động lực làm việc, thái độ hậm hực với cả team.