1. Mã không có cấu trúc
Lý do các Dev thiếu kinh nghiệm viết mã không có cấu trúc là do họ tập trung nhiều vào việc làm cho code hoạt động trong khi các Dev có kinh nghiệm thì biết rằng còn nhiều điều hơn. Viết code và làm cho nó hoạt động là một phần rất nhỏ trong công việc của một Dev mặc dù các Dev thiếu kinh nghiệm cho rằng đó là phần lớn nhất trong công việc của họ.
Khi bạn có nhiều kinh nghiệm hơn, bạn sẽ nhận ra hầu hết công việc của mình bao gồm duy trì các dự án thay vì xây dựng các dự án mới từ đầu. Sau khi bắt đầu nhận ra điều này, bạn sẽ viết mã theo một cách dễ bảo trì hơn và dễ hiểu hơn đối với các nhà phát triển khác.
Không nhận ra điều này sẽ dẫn đến những thứ như hàm với kích thước lớn,... Điều này đi kèm với rất nhiều nhược điểm - chẳng hạn như khả năng kiểm tra. Làm thế nào bạn có thể kiểm tra một chức năng thực hiện năm việc khác nhau và có kích thước lớn? Khi mục tiêu chỉ là làm cho nó hoạt động, chất lượng của code sẽ bị ảnh hưởng bởi điều này. Khi mã như thế này bước vào giai đoạn bảo trì, bạn bắt đầu cảm thấy mã thiếu chất lượng.
2. Gỡ lỗi Shotgun
Khi các nhà phát triển thiếu kinh nghiệm gặp sự cố, họ thường bắt đầu gỡ lỗi shotgun - họ thay đổi ngẫu nhiên một số nội dung trong code với hy vọng nó sẽ khắc phục được sự cố mà không biết vấn đề thực sự là gì. Rất có thể bằng cách thực hiện những thay đổi ngẫu nhiên này, bạn chỉ tạo ra nhiều lỗi hơn. Điều bạn nên làm, thay vì gỡ lỗi bằng shotgun, là thu thập thêm thông tin liên quan đến vấn đề.
Có nhiều cách tiếp cận tốt hơn khi gỡ lỗi code của bạn. Điều đầu tiên bạn cần làm là tìm ra cách bạn có thể tái tạo vấn đề và đảm bảo rằng bạn biết cách thực hiện việc này trước khi bắt đầu áp dụng bất kỳ thay đổi nào cho code của mình. Mở tệp nhật ký và xem bạn có thể tìm thấy một số thông tin hữu ích có thể dẫn bạn đi đúng hướng hay không. Điều quan trọng là thu thập thông tin trước khi bạn bắt đầu thay đổi vì bạn có thể hiểu được điều gì thực sự gây ra lỗi.
Khi bạn đã tìm ra nguyên nhân gây ra lỗi và khắc phục nó, bạn vẫn chưa hoàn thành. Nếu bạn thực sự muốn làm tốt mọi việc, bạn nên viết ít nhất một bài kiểm tra để sửa chữa. Bằng cách này, bạn sẽ được bảo vệ khi mọi thứ trong tương lai.
3. Tập trung quá nhiều vào công nghệ
Các Dev chưa có kinh nghiệm vẫn đang trong quá trình học hỏi. Do đó, trọng tâm của họ chủ yếu là trở thành bậc thầy về công nghệ. Điều này có lợi nếu bạn muốn trở thành một Dev giỏi vì bạn cần phải nắm vững công nghệ. Nhưng bạn không nên chỉ tập trung vào công nghệ.
Những gì bạn đang làm là tạo ra giá trị cho doanh nghiệp hay bạn đang dành quá nhiều thời gian cho việc gì đó không liên quan đến doanh nghiệp? Đây là một câu hỏi quan trọng mà bạn nên tự hỏi mình mọi lúc. Trở thành một Dev không chỉ là quan tâm đến các khía cạnh kỹ thuật của công việc. Hãy nhớ rằng các yếu tố kinh doanh và kinh tế là những yếu tố chứng minh sự tồn tại của công việc của bạn.
4. Khác biệt một chút
Khi làm việc trong một nhóm, doanh nghiệp có thể phát hiện ra một Dev thiếu kinh nghiệm vì họ có xu hướng làm mọi thứ theo cách riêng hơn là theo cách giống như mọi người khác. Đôi khi điều này xảy ra ngoài ý muốn vì họ không thể nhận ra.
Để làm mọi thứ theo cách giống như mọi người trong nhóm, bạn có thể xem tất cả các yêu cầu được tạo. Bạn không cần phải xem lại tất cả mà chỉ cần đảm bảo rằng bạn đã xem qua cách các Dev khác giải quyết một số vấn đề nhất định. Giải pháp của họ có giống với cách bạn khắc phục sự cố không? Nếu không, hãy hỏi tại sao họ chọn giải pháp đó và liệu họ có xem xét giải pháp của bạn không.
Kết luận
Những lỗi được nêu trên là những lỗi thường gặp của một Dev thiếu kinh nghiệm. Hy vọng bài viết có thể phần nào giúp bạn thay đổi và tiến xa hơn trong con đường sự nghiệp.
Theo jt1.vn
Japan IT Works
