Bài học đắt giá về kỹ năng lập trình có thể giúp bạn trong sự nghiệp.

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

Ví dụ về hệ sinh thái. By Alex Ivanovs

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

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

Có thể bạn muốn tìm hiểu thêm:

10 trang web học lập trình miễn phí năm 2021

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

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

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

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

#10 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ẻ 10 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é!

Xem thêm bài viết gốc tại đây !

Bạn có biết?

tham gia cộng đồng ITguru trên Linkedin, Facebook và các kênh mạng xã hội khác có thể giúp bạn nhanh chóng tìm được những chủ đề phát triển nghề nghiệp và cập nhật thông tin về việc làm IT mới nhất

Linkedin Page:
Facebook Group:
cơ hội việc làm IT : ITguru.vn