10 Sai Lầm Của Một Lập Trình Viên Tự Học (PHẦN 2)

Bài viết của Radek Busa, một full stack developer và là một tech blogger làm việc tại ICZ, một công ty phần mềm lớn tại cộng hòa Czech.

Cách đây 8 năm, tôi bắt đầu con đường lập trình của mình với tư cách là một người thích tự học. Sau đó tôi trở thành một lập trình viên tự do, thỉnh thoảng làm việc cho các công ty khởi nghiệp với ngân sách thấp. Sau một thời gian với những công ty nhỏ như vậy, tôi đã nộp đơn vào một tập đoàn lớn, nơi mà sau vài năm, sự nghiệp của tôi đã tăng vọt và tự tin về kỹ năng phát triển phần mềm của mình. Cùng với đó, tôi đang học thêm Thạc Sỹ trong lĩnh vực kỹ thuật phần mềm, nơi các gia sư đã giúp tôi có được kiến ​​thức chuyên môn trong các lĩnh vực phát triển phần mềm khác nhau và khả năng giải quyết các vấn đề logic phức tạp.

Hiện tại 25 tuổi, tôi có công việc đầu tiên sau khi tốt nghiệp và, được công nhận là một chuyên gia có thể giải quyết nhiều vấn đề phát triển phần mềm chuyên biệt, cũng được các đồng nghiệp kính trọng. Tuy nhiên, không phải lúc nào cũng suôn sẻ như vậy và đã có một giai đoạn khó khăn khi tôi là một lập trình viên tự học mà không có định hướng và chỉ tập trung vào việc làm sao để viết phần mềm thật nhanh.

Trong bài viết này, tôi sẽ chia sẻ về 10 sai lầm của một lập trình viên tự học mà bạn cần biết và tránh trước khi mắc phải.

5. Làm việc với thái độ “Chỉ cần hoạt động”

Tôi đã không tập trung vào chất lượng kỹ thuật của sản phẩm của mình. Điều thực sự duy nhất quan trọng đối với tôi là chức năng cho khách hàng và người dùng cuối. 

Tôi đã có phong cách code của riêng mình, lúc đó, tôi cảm thấy mình làm việc hiệu quả. Tôi cho rằng không ai khác ngoài tôi sẽ đọc hoặc chỉnh sửa code của mình. Đó là một sai lầm khủng khiếp.

Sau đó, một trong những dự án của tôi đã phát triển từ hình thức đặt hàng đơn giản thành một cửa hàng điện tử nhỏ. Chúng tôi muốn thuê cộng tác viên. Mọi người đọc code và gặp rắc rối với code này. Đột nhiên, tôi nhận ra rằng không phải là vấn đề ở khách hàng – đó là vấn đề của tôi – code của tôi cản trở sự phát triển kinh doanh của khách hàng vì tôi đã không tuân thủ chất lượng code và các tiêu chuẩn code đã được đưa ra. 

Giờ đây, tôi đưa tính dễ đọc của code lên đầu danh sách ưu tiên. Tôi cố gắng viết code đơn giản nhất có thể.

6. Xem hàng trăm hướng dẫn nhưng chưa bao giờ tìm hiểu sâu.

Xem các hướng dẫn của những người xây dựng các ứng dụng web tương tự như ứng dụng của tôi đã giúp tôi có được những kiến ​​thức cơ bản về lập trình thực hành. Khi tôi cố gắng giải quyết các vấn đề khó hơn, tôi đã tin tưởng sai lầm rằng những tài liệu đó đủ để giúp tôi giải quyết vấn đề gặp phải. Khi xem tất cả các hướng dẫn đó, tôi chỉ hiểu được những cấu trúc cơ bản nhất của ngôn ngữ lập trình. Tôi đã sử dụng các cấu trúc cơ bản đó để giải quyết các vấn đề phức tạp, từ đó làm ảnh hưởng đến chất lượng code, tới mức không ai muốn chỉnh sửa code đó nữa.

Sau khi hoàn thành môn học định hướng lập trình đầu tiên ở trường đại học, cuối cùng tôi đã hiểu cách học một ngôn ngữ lập trình. Không chỉ bằng cách viết code thực hành mà còn bằng cách kết hợp với sự hiểu biết thấu đáo về các khái niệm ngôn ngữ lập trình cơ bản, chẳng hạn như classes, giao diện, inheritance và closures. Vì vậy, hãy nắm chắc những phần cơ bản nhất của lập trình – ngôn ngữ yêu thích của bạn, API cốt lõi và mô hình lập trình nói chung. Điều đó cũng sẽ giúp bạn lập luận về việc thiết kế các giải pháp của mình.

7. Không sử dụng công cụ phân tích mã tĩnh (Static Code Analyzers)

Cho đến một thời điểm nào đó, tôi đã không tập trung vào việc viết code theo các phương pháp hay nhất. Tôi đã viết rất nhiều code mà tôi không yêu thích – tôi không tin rằng đó là code phù hợp cho việc đánh giá code của những nhà tuyển dụng. Vì vậy, tôi luôn từ chối gửi code của mình cho họ. Điều đó lần lượt đóng cửa một số cơ hội khá thú vị mà tôi có thể có. Sau khi từ bỏ công việc toàn thời gian đầu tiên, tôi phát hiện ra hai loại công cụ này là rất quan trọng cho quy trình phát triển phần mềm của mình:

• Các công cụ Lint/code style critique – mặc dù nhìn có vẻ hơi nhàm chán, nhưng các quy tắc ở đây dựa trên các phương pháp hay nhất để giúp khắc phục những vấn đề về code và thiết kế.
• Các công cụ Project-wide static analysis (Sonar, v.v.) – những công cụ này giúp xác định các vấn đề bảo mật và sự trùng lặp không chủ ý nằm rải rác trên các codebases lớn hơn.

8. Chưa bao giờ đọc tài liệu về Framework của mình

Tôi tự gọi mình là một nhà phát triển hình chữ π. Lĩnh vực kiến ​​thức sâu sắc chính của tôi là hai frameworks để xây dựng các ứng dụng web doanh nghiệp lớn – một để xây dựng giao diện người dùng và một để xây dựng phần backends. Bất kỳ kiến ​​thức chuyên môn nào khác mà tôi có đều là những thông tin nhỏ mà tôi sẵn sàng sử dụng trong trường hợp cần đến chúng. Nếu tôi phải mô tả các kỹ năng của mình vào thời điểm tôi còn là một người mới lập trình tự học, tôi sẽ nói rằng tôi là một nhà phát triển chưa thành công.

Một ngày nọ, không có nhiều kinh nghiệm và với cái tôi của mình, tôi đã cố gắng đăng ký một cuộc phỏng vấn vị trí lập trình viên cấp cao. Dunning-Kruger’s Curve (mô tả bên trên) gọi một tình huống như vậy là Đỉnh núi ngu ngốc (Peak of Mount stupid). Người phỏng vấn cho các vị trí cấp cao này có xu hướng xem xét kiến ​​thức framework của ứng viên khá kỹ lưỡng, bao gồm cả việc hỏi ứng viên về các chi tiết và các mảng tối khác trong framework mà họ sử dụng.

Mặc dù có thể phát triển các giải pháp cho hầu hết các vấn đề khá hiệu quả, tôi đã rất lo lắng ngay sau khi nghe câu hỏi đầu tiên mà tôi cho là rất khó và thực tế là tôi đã trượt buổi phỏng vấn đó. Dunning-Kruger’s Curve gọi một tình huống như vậy là Thung lũng tuyệt vọng (Valley of despair). Sau khi trải nghiệm đó, tôi nhận ra rằng đọc tài liệu về ngôn ngữ, framework hay thư viện là một trong những chìa khóa để thành công trong các cuộc phỏng vấn lập trình viên cấp cao và tiến gần hơn đến Dốc của sự khai sáng (The Slope of Enlightenment).

Dành thời gian để đọc tài liệu của cả hai framework đã cho phép tôi, sau ngần ấy năm, có được sự tự tin trong các cuộc phỏng vấn và gắn kết những phần kiến ​​thức khó tiếp thu được từ thực tế với nhau. Tất cả những điều đó đã giúp tôi thương lượng mức lương tốt hơn và lần lượt nhận được sự tôn trọng của các đồng nghiệp.

9. Không hiểu rõ về IDE mình sử dụng

Tôi bắt đầu hành trình phát triển phần mềm của mình bằng cách sử dụng trình soạn thảo đơn giản. Các cố vấn đại học đã  khuyến khích tôi sử dụng IDE. Cuối cùng, sau khi tôi sử dụng IDE (Integrated Development Environment), tôi đã sử dụng nó theo cách tương tự như notepad – viết code bên trong nó trong khi thực thi trình biên dịch, máy chủ, client và kiểm tra bằng cách sử dụng shell của tôi. Một cách chậm chạp tôi mo71u từ từ để việc thực thi các tác vụ đó cho IDE. Theo quan điểm của tôi, việc thực thi các tác vụ thủ công và việc áp dụng các tính năng IDE chậm chạp là những nguyên nhân giết chết năng suất khác của tôi.

Tôi khuyên bạn nên học cách làm việc hiệu quả với IDE bằng cách xem qua các tính năng của nó và tìm hiểu các tác vụ tự động hóa các thao tác thủ công được sử dụng nhiều nhất mà bạn thực hiện trong quy trình làm việc hàng ngày, chẳng hạn như:

• Các công cụ cải tiến mã nguồn – công cụ thúc đẩy năng suất tốt nhất mà IDE hiện nay cung cấp.
• Task Running – chạy trình biên dịch, trình gỡ lỗi, kiểm tra đơn vị, lints, xem nội dung cơ sở dữ liệu, v.v.
• Các tính năng chỉnh sửa văn bản tiện lợi – Xóa dòng, Đa con trỏ.
• Sử dụng phím tắt.

10. Không sử dụng lại Foreign Code

Trước đây, rất nhiều code tôi viết không phải là code mà  tôi được trả tiền để viết – nó chủ yếu là sự vá víu – mã cơ sở dữ liệu thô, các Angular component cơ bản, triển khai đối tượng DateTime tùy chỉnh v.v. Tôi không thích đọc tài liệu của các thư viện uy tín, tránh tìm kiếm các thư viện giải quyết vấn đề của mình và thay vào đó thích viết code của riêng tôi mà bây giờ đã nhận ra là vô giá trị.

Vâng, viết code cơ bản từ đầu chắc chắn sẽ giúp bạn nắm chắc những điều cơ bản. Nhưng phát triển kỹ năng sử dụng lại code ổn định từ nguồn uy tín và khả năng đọc lướt tài liệu kỹ thuật một cách hiệu quả là những yếu tố thúc đẩy năng suất.

Nguồn: https://bitly.com.vn/kugsit