10 thói quen xấu trong lập trình phá hỏng dự án phát triển phần mềm

Diem Do

Tránh các thói quen lập trình phổ biến này sẽ giúp bạn làm việc dễ dàng hơn và phần mềm của bạn thì an toàn hơn và khả năng mở rộng để khởi động.

 

Nguyên tắc Pareto cho biết khoảng 80% kết quả  là do 20% nguyên nhân gây ra. Cũng được gọi là nguyên tắc 80/20, nó có liên quan đến hầu hết các lĩnh  vực của đời sống con người.

 

Trong lĩnh vự phát triển phần mềm, nguyên tắc có thể được tóm tắt bằng cách nói rằng hầu hết những vấn đề bị gây ra bởi một số nhỏ các thói quen xấu trong lập trình. Loại bỏ chúng thì công việc của bạn sẽ dễ dàng hơn rất nhiều và năng suất cao hơn.

 

Đây là 10 thói quen lập trình là thủ phạm tồi tệ nhất:

 

1. Lỗi chính tả trong code

 

Đây là sự ngạc nhiên phổ biến, và họ đang bực mình bởi vì họ không có gì để làm với kỹ năng lập trình của bạn. Thậm chí, một tên biến hoặc một chức năng bị sai chính tả có thể phả hủy trong code của bạn. Hơn nữa, họ không thể dễ dàng nhận ra.

 

Giải pháp là gì? Làm việc trong một môi trường phát triển tích hợp (IDE) tốt hay thậm chí một trình soạn thảo văn bản văn bản lập trình cụ thể  có thể làm giảm đáng kể lỗi chính tả. Một điều khác bạn có thể làm: Chọn biến và tên tính năng mà dễ dàng đánh vần và vì thế, dễ dàng để phát hiện khi chúng bị sai chính tả. Tránh những từ như ‘nhận'(receive), dễ dàng có thể bị mắc lỗi, ‘nhận’ mà không rõ ràng. 

 

2. Thụt vào dòng hoặc định dạng trong code của bạn

 

Việc thụt vào và định dạng khác trong code của bạn làm nó trở nên dễ hiểu hơn trong nháy mắt, vì thế có những sai lầm ngay tức thì. Điều đó cũng làm cho nó khá dễ dàng hơn cho người khác để duy trì code của bạn, khi nó được trình bày một cash nhất quán.

 

Nếu bạn sử dụng IDE, nó không tự động định dạng mã của bạn, và xem xét việc chạy nó thông qua một phần mềm định dạng code đẹp hơn như Uncrustify, sẽ định dạng code một cách nhất quán theo quy luật bạn cấu hình. 

 

3. Đơn bộ hóa code của bạn

 

Đây là một thói quen tốt để viết những chức năng làm một việc và chỉ có một việc mà thôi. Điều đó sẽ giúp giữ chúng ngắn gọn và vì thế dễ để hiểu và duy trì chúng. Những tính năng dài có nhiều phần có thể thông qua chúng tạo ra nhiều khó khăn hơn để kiểm tra.

 

Một nguyên tắc nhỏ: Một chức năng nên không chiếm nhiều hơn một màn hình. Một điều khác: Nếu nó có 10 hoặc nhiều hơn lệnh “if” hoặc những vòng lặp, thì nó quá phức tạp và nên được viết lại

 

4. Hãy để cho môi trường phát triển tích hợp (IDE) của bạn gây ra cảm giác sai về bảo mật 

 

IDE và những công cụ khác cung cấp việc hoàn thành code rất tuyệt vời cho năng suất làm việc. Họ đề nghị các biến và những thứ khác dựa trên những gì chỉ có trong phạm vi, đó là những gì mà bạn phải đánh máy. Nhưng có một sự nguy hiểm với công cụ đánh máy này là bạn có thể chọn một cái gì đó bất kì bởi vì nó trông giống như những gì mà bạn mong đợi mà không cần nổ lực cần thiết để đảm bảo những gì mà bạn muốn. Về cơ bản, những công cụ này thực hiên những gì bạn suy nghĩ, khi thực tế bạn có trách nhiệm đảm bảo rằng việc suy nghĩ này là đúng.

 

Mặc dù có một ranh giới được vẽ nên. Việc thực thi code có thể loại bỏ lỗi chẳng hạn như sai chính tả và tăng hiệu suất làm việc , nhưng họ cũng có thể giới thiệu lỗi trong “việc thực thi code” nếu bạn không bắt đầu công việc.

 

5. Mật khẩu khó mã hóa

 

Thật hấp dẫn để khó mã hóa một tài khoản và một mật khẩu bí mật, bạn có thể nhận được vào hệ thống của bạn sau này. Bạn biết là bạn không nên làm điều này – Vâng đúng vậy, thật sự rất tiện lợi nhưng cũng rất thuận tiện cho tất cả mọi người những ai muốn truy cập đến mã nguồn.

 

Vấn đề thật sự này là một mật khẩu khó mã hóa cuối cùng sẽ được biết đến rộng rãi hơn những gì bạn đã dự định. Nó tạo nên một nguy cơ bảo mật lớn, không đề cập đến một sự sửa chữa bất tiện.

 

6. Không sử dụng mã hóa tốt để bảo vệ dữ liệu

 

Những dữ liệu nhạy cảm cần được mã hóa di chuyển qua đường mạng, bởi vì nó dễ dàng bị chặn khi thực hiện như vậy. Đây không chỉ là một ý kiến tốt, nó là một yêu cầu pháp lý nếu không có luật pháp. 

 

Cũng đồng nghĩa với việc gởi đi dữ liệu rõ ràng là “không không”. Nó cũng là những quy luật sử dụng mã hóa riêng của bạn hay là một sự sắp xếp rối rắm.  Viết cho hệ thống mã hóa bảo mật dành cho riêng bạn thì vô cùng khó khăn, hãy nhìn vào những gì đang xảy ra với WEP vì thế việc sử dụng một thư viện công nghiệp được chứng minh mã hóa chuẩn và sử dụng nó một cách đúng đắn.

 

 

7. Tối ưu hóa code sớm

 

Có một lần một lập trình viên huyền thoại Donald Knuth đã nói rằng “Những nhà lập trình đã lãng phí một lượng thời gian khổng lồ về những suy nghĩ hay những lo lắng, tốc độ của các phần không quan trọng của những chương trình của họ, và sự nổ lực này chỉ hiệu quả thực sự khi có sự tác động tiêu cực mạnh mẽ trong việc gỡ lỗi và sự duy trì đang được xem xét.  “

 

Hãy khéo léo trong code của bạn có thể là cho nó chạy nhanh hơn tí xíu, những làm cho nó khó khăn hơn  trong việc gỡ lỗi và duy trì. Một chiến lược tốt hơn là : Viết code rõ ràng, sau đó làm việc với bất kì phần nào mà thật sự cần  để tối ưu hóa để cải thiện hiệu suất

 

8. Không suy nghĩ trước

 

Dự án của bạn để làm gì? Quy mô mong đợi là bao nhiêu? Bao nhiêu người dùng sẽ sử dụng nó và nó chạy nhanh như thế nào?

Câu trả lời cho những điều này có thể không có sẵn , nhưng nếu bạn thất bại trong việc ước tính, và làm thế nào để bạn có thể chọn một framework thích hợp để phát triển ứng dụng sẽ có thể gặp phải những yêu cầu này?

 

Twitter cung cấp một ví dụ hay về vấn đề mà bạn gặp phải nếu bạn đánh giá không đúng mức những yêu cầu tương lai. Twitter đã phải từ bỏ Ruby trên Rails để viết lại nhiều đoạn code của nó dùng Scale và những công nghệ khác bởi vì code của Ruby được kiến trúc như ban đầu, đơn giản không thể so sánh được với nhau để giữ cơ sở người dùng của Twitter phát triển nhanh chóng .

 

9. Thêm người để bù đắp thời gian đã đánh mất

 

Hâù hết những dự án phần mềm đều bị chậm tiến độ. Việc thêm người vào dự án đúng tiến độ ban đầu có vẻ nghe như một ý tưởng hay trên lý thuyết, nhưng đó là sai sót phổ biến. Sự thật là việc thêm người mới vào một dự án hầu như luôn có kết quả trong làm giảm sút tổng thể năng suất.  

 

10. Sử dụng ước tính thời gian tồi tệ được biết đến

 

Tại cùng thời điểm, điều quan trọng để tránh các cám dỗ tưởng tượng rằng bạn sẽ bắt kịp với lịch trình làm việc của bạn sau đó mà không cần thêm người vào dự án. Nếu bạn bị chậm tiến độ, đó là vì sự ước tính thời gian của bạn có lỗi. Điều này có nghĩa bạn cần phải thực hiện một ước lượng mới về độ dài của dự án, mà không mù quáng dính vào các ước tính đã được chứng minh là sai.

Chia sẻ bài viết ngay

Nguồn bài viết : infoworld.com