+3

Nhứng sai lầm dễ mắc phải với người mới lập trình.

Giới thiệu

  • Khi bắt đầu bước vào con đường lập trình, bạn sẽ bước đi và thực hiện rất nhiều sai lầm. Vấn đề là, đôi khi bạn không biết mình đang thực hiện nó. Tôi đã rất ấn tượng với bài viết những thói quen xấu kìm hãm sự phát triển của lập trình viên, khi tôi bắt đầu vào thực hiện công việc của một lập trình viên, và hiện tại, đọc được được bài viết những sai lầm dễ mắc phải của người mới bước vào lập trình, tôi thấy rất hay và muốn chia sẻ với mọi người.

Sợ hãi và tự nghi ngờ

  • Sai lầm đầu tiên của những người mới bắt đầu bước vào lập trình là họ nghĩ mình không đủ thông minh, hay không đủ tư duy để bước vào con đường lập trình. Họ e sợ khi nhìn thấy một vài dòng code và họ phủ nhận tất cả, họ không chịu suy nghĩ, rằng tại sao lại viết những dòng code đó, những dòng code đó để làm gì, hoặc, tại sao những dòng code đó lại được đặt ở đó mà không phải ở chỗ nào khác. Phản ứng đầu tiên của họ là: "Oh, code, chắc là khó, phức tạp lắm, chắc chỉ siêu nhân mới có thể làm được", nhưng đó là sai lầm cơ bản trong việc nhận định vấn đề rồi.

  • Bất cứ một ngôn ngữ lập trình nào, khi mới bắt đầu và không có kinh nghiệm, bạn đều gặp phải rào cản. Hãy nhớ lại hồi còn đi học mẫu giáo, những mặt chữ mới khó nhớ làm sao, làm sao ghép các chữ cái thành vần, bài đọc này đọc như thế nào nhỉ? Vậy đó, lập trình bắt đầu bằng việc học ngôn ngữ, từng chút, từng chút một, bạn sẽ biểu được cần phải diễn tả cách suy nghĩ của mình như thế nào bằng ngôn ngữ lập trình. Tôi quan niệm rằng: "Học một ngôn ngữ lập trình mới, cũng giống như học ngoại ngữ, bạn cần chăm chỉ, cẩn thận, học từ mới, cấu trúc câu.v.v." Có rất nhiều điểm chung giữa chúng, và hãy nhớ rằng, ông cha ta đã có câu, vạn sự khỏi đầu nan, chẳng có gì là dễ dàng ngay từ đầu cả.

Viết code một cách bừa bãi

  • Một người lập trình có kinh nghiệm gần như ngay lập tức họ có thể nhận ra sự lộn xộn trong code của một lập trình viên mới, ví dụ như: không thụt đầu dòng, thừa khoảng trắng. Ở nhiều ngôn ngữ, trình thông dịch, biên dịch vẫn chạy tốt mới những đoạn code lộn xộn, và chức năng của function(hàm) vẫn đúng, tuy nhiên, đó là một sai lầm.

  • Việc thụt đầu dòng, hay tạo những khoảng trắng theo chuẩn là điều kiện để sắp xếp logic một cách chính xác. Việc thụt đầu dòng cho một khối lệnh, sẽ đảm bảo rằng khối lệnh đó thực hiện chức năng nào một cách rõ ràng, việc debug dễ dàng hơn, Hay trong vòng lặp for... hay chú ý đến những chuẩn viết code của nó khi bạn bắt đầu với bất kỳ một ngôn ngữ nào.

Sử dụng không thống nhất chữ hoa và chữ thường

  • Trong một số ngôn ngữ, viết hoa và viết thường được quy định rõ ràng trong tài liệu của ngôn ngữ đó, nhưng cũng có nhiều ngôn ngữ không quy định việc đó. Tuy nhiên, khi bắt đầu một ngôn ngữ, bạn nên thống nhất cách đặt tên, khi nào sử dụng chữ hoa, khi sử dụng chữ thường, bạn có thể tự quy định rằng khi đặt tên biến theo chuẩn nào.v.v. Như thế, sẽ tránh cho bạn trường hợp ngớ ngẩn như:
    # Bạn khai báo 1 biến point như sau
    var Point = 5;
    # Và ở đâu đó , bạn sẽ gọi đến biến Point, nhưng lại gọi:
    point += 1;
    # Và tất nhiên, chương trình của bạn bị lỗi, vì chẳng có biến point nào được định nghĩa. Điều đó
    # có thể tệ hại hơn, nếu ở đâu đó bạn lại khai báo 1 biến với tên là point.

Đặt tên biến và tên hàm một cách tối nghĩa

  • Sai lầm đặt tên biến và tên hàm là sai lầm dễ mắc phải nhất đối với người mới lập trình, họ có thể định nghĩa một hàm f, g, j ,k nào đó, và khi gọi đến, sử dụng chúng một cách thành thục và, đôi khi họ cũng quên chức năng nào ở hàm nào. Họ đã như vậy, còn người review code cho họ, công việc đó không phải quá khó, nhưng sẽ làm mất rất nhiều thời gian cho người đọc code của họ.

  • Hãy đặt tên biến , tên hàm một cách có ý nghĩa và gợi nhớ đến chức năng của biến, của hàm. Như vậy sẽ dễ dàng cho người review code cho bạn, cũng như những người đến sau, họ duy trì và sửa chữa hệ thống. Họ không phải phân vân hàm f này ở chỗ này làm gì, hàm f ở chỗ kia làm cái gì nhỉ, tham số đầu vào của hàm này là gì, của hàm kia là gì. Ngược lại, nếu bạn ghét ai đó, làm bản thân mình trở lên nguy hiểm hơn, thì việc đặt tên hàm và tên biến lộn xộn, linh tinh là một ý tưởng không thể tuyệt vời hơn !!!

Viết code mà không có comment

  • Nên viết comment vào những đoạn xử lý logic phức tạp, hay khi định nghĩa một hàm nào đó. Cụ thể, khi định nghĩa một hàm (function) , nên comment rằng hàm đó thực hiện chức năng gì, có những tham số nào, kiểu của tham số truyền vào là gì, và hàm đó trả về kiểu giá trị nào. Như thế sẽ dễ dàng cho việc sử dụng hàm đã được định nghĩa. Người dùng sau có thể gọi đến hàm đó mà chẳng cần biết trong hàm đó sẽ xử lý những gì, họ chỉ cần truyền tham số và sẽ trả về giá trị như thế nào. Nếu bạn là người dùng hàm đó, bạn sẽ thấy thoải mái không, thử tượng tượng,khi bạn có nhu cầu nào đó, tìm trong danh sách hàm, rồi chợt nhận ra, oh, có hàm này thực hiện chức năng đó rồi, chỉ cần tham số này... tham số kia...v.v . Quá "sung sướng" ấy chứ.

Không biết đầy đủ sức mạnh của ngôn ngữ mình sử dụng để lập trình

  • Sai lầm này thường xảy ra khi bắt đầu học một ngôn ngữ lập trình mà không chú ý kỹ. Một ví dụ nhé, khi cần tính trung bình của một cột, theo logic thông thường, chúng ta sẽ tính tổng giá trị các thành phần, sau đó chia cho số thành phần. Bạn hì hục đi làm, tính toán, viết code, trong khi trong thư viện chuẩn của ngôn ngữ, họ đã hỗ trợ việc đó rồi. chỉ cần sử dụng hàm avg(tham số), nó sẽ trả về giá trị trung bình. Như vậy công việc của bạn vừa mất thời gian, vừa mất công sức, mà hiệu quả lại chẳng khả quan.

Không sử dụng trình gỡ lỗi

  • Nếu bạn đang làm việc trong một ngôn ngữ tĩnh đánh máy như Java, C # hoặc ActionScript3, bạn nên sử dụng trình gỡ lỗi. Những ngôn ngữ này cung cấp cho bạn các lỗi thực sự chi tiết, trong đó kết hợp với một trình gỡ lỗi, có thể giúp bạn theo dõi các lỗi trong mã của bạn một cách dễ dàng.

  • Nếu bạn đang làm việc với JavaScript, các lỗi thực sự không được chi tiết, tuy nhiên vẫn còn nhiều hơn chỉ là "alert ()" để giúp bạn. Chrome cài đặt sẵn với các công cụ phát triển mà để cho bạn thấy chi tiết lỗi, mã lỗi hơn là chỉ mỗi "console.log ()" .

Không sao lưu công việc của bạn

in-case-of-fire-1-git-commit-2-git-push-3-leave-building2.png

  • Một ví dụ vui thôi. Nhưng việc có thói quen Ctrl + S sau mỗi lần thay đổi code là một thói quen tốt, điều đó giúp bạn tránh phải mất đi công sức làm việc của bạn trong thời gian trước. Biết đâu trong một ngày đẹp trời, bạn hì hục làm từ sáng đến trưa gần xong phần việc của mình, ông bạn đối diện do ngồi một tư thế quá lâu, nên đá duỗi cái chân dài miên man của ông ấy ra, và phụp, case máy tính của bạn bị mất nguồn, công sức từ sáng đến giờ của bạn theo cú đá "Nộ long cước" của ông ấy mà ra đi không thể quay lại nữa.

Luôn luôn nghĩ mình đã biết tất cả

  • Trái ngược với giai đoạn đầu bước vào lập trình, người lập trình sau khi lập trình một thời gian, sẽ có một lối suy nghĩ ảo tưởng sức mạnh rằng, cái gì mình cũng đã biết hết rồi, cái gì mình cũng có thể làm tốt, chỉ cần đưa ra vấn đề, mình sẽ làm một lúc là xong. Oh. Nếu bạn cũng có những suy nghĩ ấy, bạn có lẽ đã phải làm lập trình cả mấy chục năm rồi ấy chứ. Hãy nhớ rằng công nghệ thay đổi từng ngày, và việc cập nhật những thay đổi mới ấy luôn luôn tốt cho công việc của bạn. Hay bạn muốn trong khi cả thể giới dùng win8, win10, bạn sử dụng win98. Điều đó cũng hơi hơi buồn cười chút thôi.

Tổng kết

  • Cuối cùng, rất mong bài viết này sẽ giúp đỡ được bạn trong những bước khởi đầu trên con đường lập trình. Hãy tưởng tượng mình là chúa tể thế giới, mình muốn đối tượng A di chuyển 2 bước mỗi lần thì nó không thể đi 3 bước hay 1 bước mỗi lần, hoặc, trong ngày valentine, khi không có gấu, bạn có thể design ra một người yêu tạm thời một cách tuyệt vời. Hoặc ra làm ra một game có độ khó mà đến siêu máy tính cũng không thể chiến thắng, hay tạo ra một sản phẩm thu hàng triệu đô, và giúp bạn có mặt trong chương trình: "rich and famous". Tự tin bước tiếp con đường bạn đã chọn nhé !!!

All rights reserved

Viblo
Hãy đăng ký một tài khoản Viblo để nhận được nhiều bài viết thú vị hơn.
Đăng kí