Những sai lầm mà lập trình viên Junior thường mắc phải
Việc đẩy code chạy được chỉ là mức cơ bản. Đó không phải là mục tiêu cuối cùng.
Tôi từng review một pull request mà phải mất tới 45 phút mới hiểu được. Logic thì đúng. Các bài test đều vượt qua. Nhưng code được viết như thể chỉ có mỗi tác giả mới đọc nó vậy.
Khi tôi đưa ra phản hồi, lập trình viên đó nói: "Nhưng nó chạy được mà."
Họ nói đúng. Nó chạy được. Và đó chính xác là vấn đề.
Các lập trình viên Junior thường tập trung vào kỹ năng chuyên môn. Nhưng lỗ hổng thực sự thường nằm ở thói quen và tư duy.
Dưới đây là những sai lầm tinh vi khiến bạn chậm lại:
Viết cho bản thân thay vì cho người khác Code được đọc thường xuyên hơn nhiều so với lúc nó được viết ra. Một hàm bạn viết hôm nay có thể sẽ được ba người khác nhau chạm vào trong vòng hai năm tới. Nếu một người lạ không thể hiểu code của bạn trong vòng 30 giây, bạn đã thất bại.
Sao chép code mà không hiểu nó Sử dụng Stack Overflow là bình thường. Nhưng sao chép một mẫu regex mà không biết nó hoạt động như thế nào thì rất nguy hiểm. Bạn đang tạo ra một "hộp đen" (black box) trong codebase của mình. Bạn sẽ không thể debug được khi nó gặp lỗi.
Thêm thắt sự phức tạp không cần thiết Các Junior thường đánh đồng sự phức tạp với kỹ năng. Họ áp dụng các design pattern vào những tác vụ đơn giản. Sự trừu tượng hóa (abstraction) không cần thiết khiến code khó debug và khó thay đổi hơn. Chỉ nên thêm abstraction khi bạn thực sự cảm thấy sự thiếu vắng của nó gây ra khó khăn.
Phớt lờ các thông báo lỗi Thông báo lỗi chính là tài liệu miễn phí. Đừng vội vàng lên Google ngay khi vừa thấy một stack trace. Hãy đọc toàn bộ thông báo. Nó thường cho bạn biết chính xác dòng nào bị lỗi và tại sao.
Hỏi trợ giúp quá sớm hoặc quá muộn Đừng dành ba tiếng đồng hồ để loay hoay với một vấn đề chỉ mất 10 phút để giải quyết. Như vậy là không hiệu quả. Nhưng cũng đừng nhắn tin cho senior chỉ với một tấm ảnh chụp màn hình mà không có ngữ cảnh gì. Hãy áp dụng quy tắc 20 phút: dành 20 phút để tự tìm cách giải quyết. Ghi lại những gì bạn đã thử. Sau đó, hãy đưa tài liệu đó ra khi yêu cầu trợ giúp.
Xây dựng lại những gì đã có sẵn Trước khi viết một hàm tiện ích (utility) mới, hãy tìm kiếm trong codebase. Có khả năng đội ngũ của bạn đã giải quyết vấn đề đó rồi.
Viết commit message kém Một commit message kiểu như "fix bug" chẳng cho đội ngũ của bạn biết được điều gì. Hãy giải thích cái gì đã thay đổi và tại sao. Hãy coi lịch sử Git như một loại tài liệu.
Coi yêu cầu là luật lệ tuyệt đối Các yêu cầu thường bỏ lỡ các trường hợp biên (edge cases). Đừng chỉ thực hiện những gì được bảo. Hãy hỏi xem điều gì sẽ xảy ra khi có lỗi phát sinh.
Dừng lại ngay khi nhấn nút "Merged" Trách nhiệm không kết thúc khi PR của bạn được merge. Hãy theo dõi tính năng của bạn qua giai đoạn QA. Theo dõi nó khi chạy trên production. Đọc các báo cáo lỗi.
Lỗ hổng lớn nhất chính là tinh thần trách nhiệm. Các lập trình viên Senior không chỉ viết code. Họ giải quyết vấn đề mà không tạo ra thêm những vấn đề mới.
Đừng chỉ tối ưu hóa để "xong việc". Hãy bắt đầu tối ưu hóa để "làm tốt".