7 sai lầm của một lập trình viên tự học

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.

Trong bài viết này, tôi sẽ chia sẻ về 7 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.

#1 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ể.

#2 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.

#3 Không có nhận thức về hệ sinh thái

Ngày trước, tôi đã sử dụng một thư viện đơn giản (jQuery) kết hợp với các sáng kiến của mình để xây dựng các giải pháp khá lớn mà ngày nay tôi sử dụng framework MVC để thực hiện. Tôi từng cho rằng chỉ học và sử dụng một vài thư viện cơ bản sẽ giúp tôi giải quyết tất cả các vấn đề của mình trong quá trình phát triển web. Tôi không quan tâm đến các giải pháp thay thế có lẽ tốt hơn và hiệu quả hơn. Tôi chỉ muốn làm cho xong và tiếp tục với một dự án khác. Cuối cùng tôi đã nhận ra rằng tôi đã giải quyết một vấn đề rất đơn giản bằng cách áp dụng giải pháp phức tạp không cần thiết chỉ vì tôi đang sử dụng một thư viện dành để giải các loại vấn đề khác nhau.

Theo kinh nghiệm của tôi, không có framework, ngôn ngữ hay thư viện nào là tiên quyết để giải quyết tất cả các vấn đề một cách hiệu quả. Ngày nay, mỗi khi vấp phải một vấn đề mới, tôi cố gắng tìm kiếm các giải pháp ổn định và được thiết kế tốt để giải quyết vấn đề đó với ít nỗ lực nhất có thể.

#4 Không dùng Testing Unit

Tôi đã quá tự tin vào code của mình. Tôi đã thử nghiệm code của mình một cách đặc biệt bằng cách viết code calls, ghi nhật ký, kiểm tra bằng tay.. Sau đó, một lỗi trong cùng một code xuất hiện và tôi đã viết lại testing code tương tự. Rất lãng phí thời gian!

Sau nhiều năm tích lũy các kỹ năng cứng về lập trình và kiểm thử, đây là những lợi thế chính của lý do tại sao nên viết các bài unit test bằng cách sử dụng unit testing framework:

• Mang lại sự tự tin về code mà nó kiểm tra vì nó có thể lặp lại sau mỗi lần thay đổi.
• Giúp khắc phục các thiết kế API tệ hại.
• Giúp thiết kế hướng đối tượng tốt hơn.
• Một loại tài liệu luôn đồng bộ với code.

#5 Sao chép code quá nhiều

Tôi vẫn duy trì một số dự án thực sự là một “cơn ác mộng” . Bên cạnh việc thiếu hiệu quả của dev stack, là còn liên quan đến trùng lặp – không chỉ mã copypasted mà còn code thiếu tính trừu tượng – các chức năng phổ biến không được trích xuất vào các functions/superclasses, magic values không được trích xuất vào contants.. Có lẽ điều đó bắt nguồn từ thực tế là các ngôn ngữ lập trình đầu tiên của tôi là HTML và CSS, ở dạng ban đầu, sự trùng lặp là phổ biến.

Mỗi khi khách hàng muốn chuyển việc bảo trì dự án của tôi cho người khác, những người đó đều không nhận và coi tôi là một lập trình viên tồi và kết quả của tôi là thảm hại về mặt kỹ thuật.

Từ khi một đồng nghiệp của tôi đã truyền cảm hứng cho tôi để xây dựng các giải pháp có thể tái sử dụng, trừu tượng và theo hướng dữ liệu, tôi luôn nghĩ đi trước một bước khi thiết kế các giải pháp của riêng mình và cố gắng nghĩ làm thế nào để code của tôi sau này có thể được sử dụng hay tái sử dụng.

#6 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.

#7 Không quan tâm đến cải tiến code

Nhiều lần khi bắt đầu sự nghiệp lập trình viên của mình, tôi đã tạo ra các giải pháp đơn giản, sau đó đã mở rộng khá nhiều sau khi đưa vào sử dụng chính thức. Khách hàng của tôi thường xuyên muốn thiết kế lại, thêm các tính năng mới hoặc thay đổi để tuân thủ GDPR. Để làm cho họ hài lòng bằng cách giảm chi phí, tôi luôn phát triển những gì họ cần trong khi không bao giờ quan tâm đến code cũ từ các phiên bản trước của sản phẩm.

Technical debt: Vòng luẩn quẩn. By Tushar Sharma

Giờ đây, tôi xem việc cải tiến code liên tục (refactoring) như một thông lệ tiêu chuẩn trong quy trình phát triển phần mềm của mình. Mỗi khi cần, tôi thêm chi phí cải tiến này vào tổng chi phí phát triển của một tính năng. Và sau khi giải thích những chi phí bổ sung đó cho khách hàng của mình, tôi gần như luôn cảm thấy thích thú với điều đó.

Kết luận

Trong bài viết này, tôi đã chia sẻ 7 sai lầm mà tôi đã mắc phải khi còn là một lập trình viên tự học. Nếu bạn đang cố gắng trở thành một lập trình viên tự học, hãy ghi nhớ những điều này và tránh những sai lầm. Nếu tình cờ là một lập trình viên có kinh nghiệm đọc được điều này, đừng ngần ngại chia sẻ những sai lầm của bạn từ những ngày đầu khởi nghiệp bằng cách bình luận ngay ở dưới bài viết nhé!

Học lập trình có việc ngay trong 6 tháng: tham khảo