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

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.

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

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

3. 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.

4. 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. 

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 đó.

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