- vừa được xem lúc

12 lỗi sai mà mọi lập trình viên nên tránh!

0 0 14

Người đăng: Bách Nguyễn Ngọc

Theo Viblo Asia

Trong hành trình xây dựng phần mềm, mỗi lập trình viên đều gặp phải những thách thức riêng biệt. Tuy nhiên, có những lỗi phổ biến mà ai cũng nên tránh để đảm bảo rằng dự án của họ làm việc mượt mà và hiệu quả. Bài viết này sẽ điểm qua 12 lỗi phổ biến mà mọi lập trình viên nên biết và tránh. Hãy cùng nhau tìm hiểu để tối ưu hóa quá trình phát triển phần mềm và nâng cao chất lượng code nhé!

1. Tên biến không rõ ràng

Biến (Variables ) là một phần quan trọng của lập trình, bất kể bạn sử dụng ngôn ngữ nào. Đó là lý do tại sao bạn cần hình thành thói quen tốt khi đặt tên cho biến của mình. Nếu bạn sử dụng các thuật ngữ chung chung tổng quát và vô nghĩa, hay ý nghĩa sai lệch, bạn có thể tạo ra một mớ hỗn độn cho chính mình sau này. Code của bạn có thể chạy tốt, nhưng khi bạn quay lại xem nó vào một thời điểm sau này, bạn có thể sẽ bị lạc trong chính mớ hỗn độn do mình tạo ra, và lúc đó bạn sẽ phải cố gắng tìm hiểu xem code của mình đang làm gì và biến đó đang nói về cái gì.

Và nếu một lập trình viên khác đang làm việc với bạn hoặc phải maintain (bảo trì) code của bạn sau này, mình tin bạn chắc chắn sẽ làm cho cuộc sống của họ trở nên khó khăn hơn bao giờ hết bằng cách đặt tên biến kiểu như vậy. ("Stop and change that immediately 🤧🤧")

2. Code bị lặp lại

Nếu bạn phát hiện mình đang lặp lại code, bạn đang vi phạm một trong những nguyên tắc cơ bản nhất của phát triển phần mềm - DRY (Don't Repeat Yourself - Đừng Lặp Lại Chính Mình). Hãy cố gắng tuân thủ nguyên tắc DRY. (Mình đã nhắc đến nguyên tắc DRY ở trong bài viết này)

Mỗi khi bạn tự thấy mình đang sao chép và dán mã code, bạn cần nhận ra được rằng có khả năng mình đang vi phạm nguyên tắc DRY và nên tự kiểm tra lại. Bạn có thể vượt qua vấn đề này bằng cách sử dụng vòng lặp và hàm. Hoặc đơn giản là hãy cẩn thận và chú ý hơn.

Có một điều bạn cũng có thể dễ dàng nhận ra được đó là bạn cần phân tích nghiệp vụ trước khi đặt tay vào bắt đầu code, nhóm các tác vụ hay một nghiệp vụ giống nhau về logic vào một hàm, và sử dụng hàm này ở các đoạn logic chung. Như vậy cũng sẽ giảm thiểu được khá nhiều các đoạn code lặp lại.

3. Sử dụng một ngôn ngữ quá phức tạp

Bạn không cần phải bắt buộc bản thân mình lập trình bằng một ngôn ngữ mà bạn không hiểu, chỉ vì bạn thấy người khác đang sử dụng ngôn ngữ đó. Và nếu bạn đang muốn bắt đầu lập trình và đang cố gắng thành thạo một ngôn ngữ, đây là một ý tưởng cực kỳ xấu. Có nhiều ngôn ngữ thân thiện với người mới học lập trình mà bạn có thể thấy dễ sử dụng hơn. Bắt đầu với một trong những ngôn ngữ này và bạn sẽ thấy nó dễ học ngôn ngữ khác sau khi bạn thành thạo ngôn ngữ đầu tiên của mình. Một vài ví dụ cho sự khởi đầu: Python, Javascript, Java...

4. Nhảy qua quá nhiều ngôn ngữ một lúc

Chạy qua nhiều ngôn ngữ cùng một lúc là một ý tưởng kinh khủng. Bạn sẽ cảm thấy vô cùng lạc lõng. Nếu bạn liên tục bắt đầu với một ngôn ngữ và chuyển sang ngôn ngữ khác sau vài tuần, điều đó thực sự là một ý tưởng tồi. Chỉ cần chọn một ngôn ngữ, kiên trì với nó và thành thạo nó. Bạn có thể quyết định học một ngôn ngữ khác sau khi đã thành thạo ngôn ngữ đầu tiên, nhưng đừng bắt đầu với một chuỗi liên tục chuyển đổi ngôn ngữ.

Có thể bạn sẽ thấy vui khi viết vào CV nộp cho nhà tuyển dụng hàng tá ngôn ngữ mà chẳng thành thạo bất cứ thứ gì trong đó, ngôn ngữ nào với bạn cũng như đứa trẻ mới lớn, và khi nhà tuyển dụng hỏi, mình tin bạn sẽ được nhớ lại hình ảnh khi của bản thân hồi chập chững biết nói.

5. Format code một cách quá tệ hại

Rất nhiều người mới học lập trình không quan tâm đến việc đảm bảo định dạng code của mình một đúng đắn vì code có thể chạy mà không gặp lỗi ngay cả khi nó được viết một cách lộn xộn và không nhất quán. Nhưng điều này sẽ làm cho bạn đau đầu khi bảo trì và phát triển code của mình trong tương lai... và càng khó khăn hơn nếu một lập trình viên khác phải làm điều này thay bạn (Mình tin lúc này họ sẽ hỏi thăm sức khỏe bố mẹ bạn khá nhiều đấy =))))

Một vài lỗi sai phổ biến về định dạng code bao gồm:

  • Không sử dụng thụt lề đúng trong code của bạn (code mà cứ thụt thò, không theo một quy chuẩn nào thì nhìn đúng là cay thật).
  • Sử dụng dòng mới và khoảng trắng không nhất quán hoặc nhét tất cả vào một dòng.
  • Viết các hàm quá lớn hoặc nhét tất cả vào một dòng, hàm hoặc tệp.
  • Sử dụng chữ hoa và chữ thường trong tên biến một cách ngẫu nhiên.

Đây không phải là một danh sách đầy đủ về các lỗi định dạng. Có nhiều lỗi định dạng khác mà bạn có thể phạm phải trong code của mình, đặc biệt là nếu bạn là người mới học lập trình.

Hãy đảm bảo rằng bạn đang code một cách có cấu trúc, sạch sẽ, dễ đọc và dễ bảo trì.

6. Không Tạo Bản Sao Lưu

Đây là một trong những sai lầm không thể tha thứ nhất mà bạn có thể mắc phải, ngay cả khi bạn mới bắt đầu hay đã là một lập trình viên kì cựu. Hãy tưởng tượng bạn đã làm việc trên một dự án trong thời gian dài, mệt mỏi với nó, và sau đó hệ thống của bạn bị crash và bạn mất hết công sức của mình. Mình nghĩ nó sẽ đau đớn lắm đấy, công sức cả một buổi tối, hay thập chí cả một tuần giời bị lãng phí có thể sẽ xảy ra vào một ngày bạn yêu đời nhất đấy, nếu không ghi nhớ điều này.

Bạn nên lưu công việc của mình đều đặn và tạo bản sao lưu. Sử dụng kiểm soát phiên bản (SVN hoặc Git), Github, hoặc thậm chí Dropbox để duy trì bản sao lưu của công việc của mình.

7. Code quá phức tạp

Bạn không phải đang cố chứng minh cho thế giới thấy bạn có thể sử dụng các hàm phức tạp nhất và các tuyệt chiêu code ấn tượng nhất mà con người biết đến (thậm chí là tự sáng tạo ra). Mục tiêu của bạn, khi viết code, nên là giải quyết vấn đề một cách hiệu quả nhất có thể. Nếu code của bạn đơn giản, nó sẽ dễ viết, bảo trì và quản lý. Chỉ đơn giản là bạn nên tuân theo nguyên tắc KISS (keep it simple, stupid - giữ nó đơn giản, ngốc) tốt nhất trong khả năng của bạn. (Mình đã nhắc đến nguyên tắc KISS ở trong bài viết này)

8. Không có kế hoạch

Viết code mà không trải qua các giai đoạn suy nghĩ, nghiên cứu và lên kế hoạch cho dự án là một ý tưởng tồi đấy. Bạn sẽ không thực sự hiểu rõ yêu cầu và các giới hạn của vấn đề, cũng như sẽ không xem xét tất cả các kịch bản có thể xảy ra.

Kết quả? Chỉ đơn giản là bạn có thể bị rơi vào một tình huống khó khăn trong tương lai (tệ hơn là code gần xong rồi thì phải đập đi xây lại). Những lập trình viên có kinh nghiệm, cho dù là những lập trình viên kỳ cựu nhất, thường dành phần lớn thời gian của họ để suy nghĩ, lên kế hoạch, nghiên cứu và thảo luận về toàn bộ dự án và chỉ chiếm khoảng 10% thời gian để thực sự viết code. (Một khi bạn đã hiểu về những gì mình cần làm, thì code nó sướng lắm)

9. Đặt quá nhiều công việc vào một hàm duy nhất

Bạn có thể sử dụng một hàm để thực hiện nhiều nhiệm vụ, nhưng điều đó không có nghĩa là bạn nên làm như vậy. Chỉ cần tuân theo nguyên tắc Single Responsibility, theo đó một hàm chỉ nên chịu trách nhiệm thực hiện một công việc. Nếu một hàm đang thực hiện nhiều nhiệm vụ, bạn đang tự chuốc lấy rủi ro và các tác động tiêu cực đến nhiều thứ khác nhau đấy.

Thinking thật nhiều và cố gắng hạn chế hết mức có thể nhé

10. Số Phép Thuật và Chuỗi Bí Ẩn

Số phép thuật (Magic Numbers) là những giá trị cụ thể xuất hiện trong code mà không có giải thích rõ ràng về ý nghĩa của chúng. Thay vào đó, nên sử dụng các hằng số có tên để mô tả ý nghĩa của các giá trị đó. Điều này giúp làm cho code trở nên rõ ràng, dễ hiểu hơn và dễ bảo trì hơn.

Ví dụ về sử dụng Magic Number: image.png

Trong đoạn mã trên, số 3.14 được gọi là Magic Number vì không có giải thích nào về tại sao nó được sử dụng làm hệ số trong tính toán diện tích hình tròn.

Giải pháp là sử dụng hằng số có tên:

image.png

Trong đoạn mã này, chúng ta đã sử dụng hằng số có tên PI để thay thế cho Magic Number. Bây giờ, khi đọc code, người đọc có thể hiểu rõ rằng chúng ta đang sử dụng giá trị PI để tính diện tích hình tròn.

Tương tự, nguyên tắc này cũng áp dụng cho chuỗi:

image.png

Chúng ta có thể sử dụng hằng số có tên để làm cho code dễ đọc hơn:

image.png

Bằng cách này, code sẽ trở nên rõ ràng hơn và dễ bảo trì hơn.

11. Hard-coding mọi thứ

Việc mã hóa cứng (Hard-coding) liên quan đến việc nhúng dữ liệu trực tiếp vào code của một chương trình hoặc các đối tượng thực thi khác, thay vì lấy dữ liệu từ nguồn bên ngoài hoặc tạo nó tại thời điểm chạy.

Vấn đề là bạn không thể cấu hình giá trị được mã hóa cứng. Đó là những giá trị cố định.

Nếu bạn thường xuyên thực hiện việc mã hóa cứng nhiều thứ, mình nghĩ bạn nên xem xét lại . Sau này khi có bất cứ sự thay đổi nào, bạn mới thấy nó thật khó chịu và mất thời gian khi lại phải vào sửa đổi bằng tay những thứ mình đã fix cứng vào trong code. Hơn thế nữa còn vô hình chung tạo nên sự phức tạp cho code của mình. Mình cũng đã đề cập tới điều này trong bài viết này).

12. Không Sử Dụng Trình Gỡ Lỗi (Debugger)

Nếu bạn gặp một lỗi code mà bạn không thể hiểu được, đừng lãng phí thời gian của bạn bằng cách nhảy vào code và cố gắng tìm hiểu một mình. Chỉ cần sử dụng trình gỡ lỗi của bạn (hầu hết các IDE đều được tích hợp).

Trình gỡ lỗi giúp bạn dễ dàng giải quyết các vấn đề. Bạn sẽ có thể theo dõi code của mình chạy từng dòng, giúp bạn nhìn thấy chính xác điều gì đang xảy ra với code của bạn. Vì vậy thành thạo debug cũng là một kĩ năng tối quan trọng đấy nhé.

Khi bạn bắt đầu hành trình của mình trong thế giới lập trình, tránh những sai lầm phổ biến này có thể giúp bạn xây dựng code một cách sạch sẽ, dễ đọc, và dễ bảo trì. Đừng để những sai lầm này tạo ra những trở ngại không cần thiết trong sự phát triển của mình. Ghi nhớ nó và cùng phóng về phía trước nào 😘😘🚀🚀

Bình luận

Bài viết tương tự

- vừa được xem lúc

12 best practices với VueJS

Giới thiệu. Xin chào tất cả các bạn, hôm nay mình sẽ giới thiệu với các bạn một số lưu ý khi coding vuejs. Không dài dòng nữa mình bắt đầu luôn nhé. Vì sao cần phải sử dụng :key , vì nó sẽ giúp giữ lại các state của component.

0 0 196

- vừa được xem lúc

Naming rules - Các quy tắc vàng trong làng đặt tên

. . Đã bao giờ bạn gặp khó khăn khi phải suy nghĩ nên đặt tên biến/hàm như thế nào trong lúc code.

0 0 34

- vừa được xem lúc

5 phương pháp thực tế đáng lưu ý nhất khi khai báo biến trong Javascript

Đôi lời dẫn nhỏ nhỏ... Sau khi đọc xong, cảm giác đầu tiên mình nghĩ ngay tới đó chính là "mình" của nhiều năm trước khi mới tập toẹ viết code Javascipt. Rồi mình chợt nhận ra có những điều mà nhiều bạn sinh viên hay thậm chí cả những bạn đã đi làm được một thời gian vẫn hay mắc phải. Song, do chưa

0 0 34

- vừa được xem lúc

Javascrpit clean code

Konnichiwa mina-san, hôm nay mình sẽ giới thiệt một số tips để code các bạn được clean hơn. . Variables. Functions.

0 0 33

- vừa được xem lúc

[Nodejs thực chiến] Để là chuyên gia npm

Đã làm node thì ngày nào cung phải dùng npm. Việc nắm chắc npm giúp bạn quản lý dependence tốt hơn, nâng cao độ ổn định, tính bảo mật của phần mềm, cũng như hiệu suất làm việc.

0 0 72

- vừa được xem lúc

[Use Case - 002] AWS EKS Security (Kubernetes on AWS)

Hôm nay chúng ta tiếp tục series AWS Use Case với một chủ đề cũng khá hay liên quan đến Kubernetes AWS mà người ta biết đến nó với cái tên AWS Elastic Kubernetes Service (AWS EKS). Với nền tảng K8S tự

0 0 40