Mọi người luôn nói rằng bạn nên làm việc với các dự án khác nhau. Nhưng ban đầu, làm việc với những dự án đơn giản với sự tỉnh táo sẽ tốt hơn là cố gắng hoàn thành một dự án phức tạp. Cái sau chỉ nâng cao cái tôi của bạn, nhưng cái trước dạy cho bạn kiến thức mà bạn có thể áp dụng cho toàn bộ hành trình lập trình của mình. Đây là điều tôi muốn nói về việc bạn phải thử nghiệm với chánh niệm. Bạn phải chủ động trong việc học của mình.
- Thử nghiệm ngụ ý thất bại: Bạn phải mất X khoảng thời gian để tìm ra những gì “không” nên làm.
- Thử nghiệm cũng bao hàm sự sáng tạo: Bạn phải thử các phương pháp khác nhau để làm những việc giống nhau và so sánh chúng để tìm ra cách nào tốt hơn. - Thử nghiệm cũng có nghĩa là mạo hiểm: Bạn phải bắt tay vào các dự án mã hóa thể hiện các phần khác nhau của ngôn ngữ lập trình mà bạn đang cố gắng học.
- Thử nghiệm cũng ngụ ý làm một cách chậm rãi: Bạn không cần phải hoàn thành công việc một cách vội vàng. Thay vào đó, hãy chăm chỉ thực hiện tất cả các bước lập trình: thiết kế -> mã giả -> mã -> kiểm tra -> gỡ lỗi -> tài liệu. Thực hiện các bước này nhiều lần đối với các thiết kế khác nhau và so sánh ưu và nhược điểm của từng thiết kế. Lập trình là một nỗ lực lặp đi lặp lại. Tiếp cận thử nghiệm của bạn theo cùng một cách: lặp đi lặp lại và hiểu rõ .
Bạn có lập kế hoạch viết code trước khi viết không? UML là viết tắt của Unified Modeling Language. Nó cung cấp một cách để hình dung các thành phần trong hệ thống. Có được "bức tranh lớn" chỉ là một cách sử dụng UML. Đối với một nhà phát triển, nó giúp lập danh mục tất cả các trình tự và hoạt động cũng như các thành phần và trạng thái của các đối tượng.
Lấy một tập giấy vẽ và chỉ cần đặt nó ra. Sau đó, tìm ra các con đường khác nhau để đi đến cùng một giải pháp. Thông thường, có những đánh đổi trong các lộ trình khác nhau. Bạn có thể tìm ra cách tốt nhất để viết mã một phần của sơ đồ, nhưng bạn có thể phá vỡ một phần khác của sơ đồ. Đây là lợi ích của việc lập kế hoạch.
Lấy code bạn vừa viết, sau đó nghĩ cách để làm cho nó tốt hơn. Tại sao bạn viết nó theo cách này lần đầu tiên? Bạn có viết nó khác lần thứ hai không? Rất nhiều người mới bắt đầu quên rằng viết code là một quá trình lặp đi lặp lại. Ngay cả khi chức năng của bạn hoạt động, điều đó không có nghĩa là bạn có giải pháp tốt nhất hiện có. Điều quan trọng là tìm ra những gì không nên làm.
Không phải lập trình viên nào cũng là lập trình viên giỏi. Ngay cả khi ai đó có chức danh Developer cấp cao, điều đó không có nghĩa là họ có thể dạy bạn những kỹ năng phù hợp. Cách tốt nhất là bạn cần tìm hiểu xem các chuyên gia trong lĩnh vực của bạn là ai. Bạn có thể vào các diễn đàn lập trình nơi các dev thường xuyên đăng liên kết đến các dự án mã nguồn mở của họ.
Tìm các nhà phát triển bằng ngôn ngữ bạn đang lập trình và xem code trong các dự án mã nguồn mở của họ. Đừng lo lắng nếu code của người khác trông xa lạ với bạn. Hãy vẽ sơ đồ tất cả các thành phần code và xem xét, đánh giá kỹ lưỡng code của họ. Bạn hãy cố gắng tìm ra những cách tiếp cận tốt nhất mà họ đã sử dụng trong code của mình và nếu có thể, hãy nhờ họ hướng dẫn bạn một số đoạn code nào đó để bạn có thể thấy cách họ triển khai như thế nào.
Ý tôi là, đôi khi nó thực sự khủng khiếp. Nhưng, một điều mà nó dạy cho bạn là không nên làm gì. Điều đó rất hữu ích trong công việc. Khi bắt đầu hành trình lập trình của mình, tôi đã dành rất nhiều thời gian để gỡ lỗi mã cũ. Vào thời điểm đó, 50% thời gian của tôi dành để thiết lập cấu hình, sửa lỗi cho các bản phát hành, cung cấp hỗ trợ cho nhân viên hỗ trợ hệ thống và tạo tài liệu.
Tôi đã từng rất ghét việc này nhưng nhờ đó tôi đã học được tích lũy được rất nhiều kinh nghiệm và không phải lãng phí quá nhiều thời gian để sửa chữa sai lầm. Hành trình để trở thành code giỏi không hề dễ dàng, nếu muốn đến đích, bạn phải sẵn sàng vượt qua chông gai. Hiện tại tôi không còn phải debug các code cũ nữa nhưng tôi đã biến nó trở thành thói quen xem lại code của chính mình đã viết một năm trước. Tôi kiểm tra và viết lại một số phần như một bài tập để giữ cho những kỹ năng của mình luôn được cập nhật.
Không phải tự nhiên mà hacker có xu hướng là những lập trình viên siêu thông minh. Ý tôi không phải khuyên bạn trở thành hacker mà bạn có thể trở thành "hacker" của riêng mình. Bằng cách phá vỡ một đoạn, bạn sẽ thấy mối quan hệ với các phần khác của code. Đôi khi bạn sẽ tìm thấy rất nhiều sơ hở trong code của mình và tìm ra giải pháp đơn giản cho code của mình.
Thường thì bạn sẽ không đạt được điều này ngay lần đầu tiên trở thành "hacker" nhưng hãy thử nghiệm thật nhiều lần với những đoạn code phức tạp dần, rồi bạn sẽ bất ngờ về thành quả mình đạt được.
Bây giờ, sau năm đầu tiên vượt qua công việc viết code “vất vả”, bạn đã sẵn sàng để tăng năng suất của mình. Bạn tăng năng suất của mình chỉ đơn giản bằng cách thực hiện từng thói quen tốt vào cuộc sống lập trình của bạn. Dưới đây là danh sách những thói quen tốt tôi đã xây dựng mà bạn có thể tham khảo: - Dành hai giờ mỗi ngày để học các khái niệm lập trình mới.
- Tập thể dục trong một giờ trước khi bắt đầu ngày làm việc của mình.
- Dành ít nhất một giờ mỗi ngày để học hỏi từ người cố vấn của mình.
- Dành thời gian theo đuổi những sở thích khác vào cuối tuần.
- Suy nghĩ về những vấn đề khó khăn trong công việc khi nghỉ ngơi như những bài tập trí óc. (Đó là một thói quen cầu toàn của tôi. Bạn có thể không muốn làm điều này tùy thuộc vào mức độ sức khỏe tinh thần của bạn.)
- Đọc sách về lập trình đều đặn hàng tháng.
- Tôi ngủ tám giờ mỗi đêm bất kể tôi đã làm việc bao nhiêu giờ vào đêm hôm trước. (Nhìn lại, đây là một điều xa xỉ.)
Trở thành một lập trình viên tốt hơn, bạn cần bắt đầu với thái độ đúng đắn và dành thời gian để biến nó thành hiện thực. Vừa rồi là chia sẻ từ kinh nghiệm thực tế của tôi, chắc chắn bạn sẽ tìm ra cách phù hợp với mình nhất qua thời gian, vậy bạn còn chờ gì nữa?
>>> Xem thêm: Lộ trình học lập trình từ cơ bản đến nâng cao
Theo: Jun Wu - medium