Sự khác biệt giữa một Lập trình viên giỏi và một Lập trình viên tệ có thể không phải là kỹ năng lập trình.
Trong thực tế, điều khiến các Lập trình viên đứng ở level khác nhau là do cách họ đối mặt với nhưng "Thói quen xấu".
Thật vậy, những thói quen xấu có thể gây hại đến mức họ có thể biến một lập trình viên tiềm năm thành một lập trình viên tầm thường, thậm chí gián tiếp đá họ khỏi ngành lập trình.
Và điều này cũng rất đúng trong lập trình Web, bất kể bạn là lập trình viên có kinh nghiệm hay nếu bạn mới bắt đầu học lập trình.
Vì vậy, tôi tự hỏi:
5 thói quen xấu khi lập trình mà tôi thực sự thấy và trải nghiệm trong quá trình làm việc là gì?
5 Thói quen Xấu Lập trình viên cần tránh
Và làm thế nào bạn có thể tránh những thói quen xấu đó?
Hãy cùng tôi tìm hiểu trong bài viết này...
1: Thói quen sử dụng mã mà không thực sự hiểu nó
Sử dụng mã mà không thực sự hiểu nó
Hãy thừa nhận điều này: Bạn đã sử dụng mã mà chẳng hiểu nó làm gì ít nhất 1 lần trong đời.
Tôi chắc chắn cũng đã như thế (thậm chí nhiều hơn một lần)
Đây là các nhanh khi chúng ta muốn chức năng trong web của mình thực sự hoạt động mà chư nghĩ ra cách làm.
Bạn chỉ cần sao chép trên Stack Overflow một đoạn mã thực sự hoạt động và chỉ cần một vài thay đổi nhỏ mà chẳng cần ngồi ngẫm nghĩ về việc tại sao nó lại hoạt động. (Người ta hay gọi là Copy - Paste đó)
Tôi biết, làm việc này rất khỏe mà lại cực kỳ hiệu quả, nhưng...
ĐỪNG SỬ DỤNG MÃ MÀ KHÔNG THỰC SỰ HIỂU NÓ!
Bạn không bao giờ nên chỉ làm một ứng dụng cho xong trừ khi bạn hoàn toàn hiểu cách thức hoạt động của nó.
Nếu không có vấn đề gì phát sinh thì không sao.
Tuy nhiên, nếu có phát sinh:
Làm thế nào bạn có thể cải thiện, sửa chữa hoặc thậm chí gỡ lỗi một đoạn mã mà bạn không thể hiểu?
Từ bỏ thói quen này cũng khá đơn giản:
Trước khi sử dụng một đoạn mã, hãy đọc nó lại vài lần, suy nghĩ tại sao nó lại được viết như thế, bạn có thể thay đổi tùy biến thế nào.
Việc này cần có thời gian, nhưng nó chắc chắn có giá trị lâu dài cho bạn.
2. Thói quen xấu "Để mai sửa"
Thói quen xấu "Để mai sửa"
Nhiều lúc, bạn phát hiện ra rằng một đoạn mã có lỗi nghiêm trọng hoặc lỗi logic có thể bị kích hoạt trong một số trường hợp.
Có thể mã đó vẫn hoạt động bình thường và chỉ không hoạt động trong các điều kiện nhất định hoặc không thể xử lý một số đầu vào cụ thể hoặc có thể tiềm ẩn lỗi bảo mật.
Nhưng Lỗi có khả năng xảy ra, và bạn biết nó có khả năng xảy ra phải không?
Trong những trường hợp này, bạn có thể tự nhủ rằng: "Âu kê, để mai sửa"
Nhưng bạn không bao giờ nên tự nhủ như thế. Bởi vì, chúng ta thừa biết rằng, chỉ qua vài dòng code nữa thôi, bạn sẽ quên béng cái lỗi đấy nó có tồn tại.
Đây là những gì sẽ thực sự xảy ra:
Chừng nào lỗi còn tồn tại, bạn sẽ buộc phải viết cách khắc phục và sửa lỗi tạm thời ở bất cứ đâu trong ứng dụng của bạn trước khi quá muộn để sửa chữa.
"Để mai sửa"... Cuối cùng, thì không biết mai là ngày mai hay mai kia... Cái này thực sự không tốt.
Tất nhiên, không phải mọi lỗi lập trình đều cần được sửa ngay lập tức.
Nhưng điều quan trọng là không nên tiếp tục tự nhủ như vậy mà cần phải lên kế hoạch sửa chữa nó ngay lập tức.
Làm thế nào để bạn tránh thói quen xấu này?
Điều tốt nhất cần làm là khắc phục mọi vấn đề ngay lập tức, nhưng tôi biết rằng không phải lúc nào cũng có thể.
Trong những trường hợp này, hãy đánh dấu đoạn mã có thể gây ra lỗi bằng comment (như / * Bugfix * /) và thêm ngay công việc vào trong kế hoạch làm việc của bạn.
Nên sớm nhất có thể, có nghĩa là trong 2 - 3 ngày (nhiều hơn thế sẽ khiến bạn quên đi các chi tiết lỗi!)
Hoặc ngay khi bạn hoàn thành công việc hiện tại của mình, một lần nữa:
LÊN KẾ HOẠCH SỬA LỖI CỤ THỂ, NGAY!
3. Thói quen không Viết Comment khi lập trình
Không Viết Comment khi lập trình
Các lập trình viên thường không viết comment vì viết comment sẽ mất chút thời gian.
Tuy nhiên, mặc dù đúng là việc viết comment mất một chút thời gian, nhưng về lâu dài nó thực sự giúp bạn tiết kiệm rất nhiều thời gian lập trình.
Viết comment buộc bạn phải hiểu và xem lại logic trong đoạn mã của bạn. Một quy trình cho phép bạn bắt lỗi và dự đoán lỗi tiềm ẩn ngay lập tức. Nó giống như một bản pre-debug.
Comment cũng liên quan chặt chẽ đến khả năng sử dụng lại của các đoạn mã.
Sử dụng lại đoạn mã của riêng bạn có thể giúp bạn tiết kiệm thời gian hàng giờ, hàng ngày, thậm chí hàng tuần để lập trình.
Nhưng…
Bạn đã bao giờ thử nhìn vào mã bạn đã viết trước đó chưa? Nếu nó không được comment đầy đủ, rất có thể bạn lại tự chửi "thằng ch*o nào viết ngu thế này"
Đây là lý do tại sao viết comment là chìa khóa để tái sử dụng mã, debug hiệu quả.
Comment cũng có nhiều lợi ích khác, bao gồm cung cấp tài liệu tham khảo cho các lâp trình viên khác.
Tuy nhiên, không quá ngạc nhiên khi rất nhiều Lập trình viên không comment đúng ý nghĩa mã của họ. Và tôi thừa nhận rằng: Tôi cũng có thói quen xấu này.
Nhưng hãy tin tôi: Nếu bạn bỏ thói quen xấu này và bắt đầu viết comment mỗi khi bạn lập trình... Bạn sẽ sớm thấy công việc lập trình nhẹ nhàng hơn rất nhiều.
Chiến lược số 1 của tôi để bắt đầu cải thiện việc viết comment là:
VIẾT COMMENT TRƯỚC KHI VIẾT BẤT KỲ ĐOẠN CODE NÀO!
Ví dụ. Bạn sẽ viết một chức năng? Bắt đầu với một comment cho hàm, mô tả mục đích của nó, các đối số và giá trị trả về của nó. Sau đó, việc tiếp theo mới là viết mã logic.
4: Đánh giá thấp tính bảo mật
Đánh giá thấp tính bảo mật
Các trang web có thể được sử dụng bởi bất kỳ ai qua Internet, kể cả người dùng có ý đồ xấu.
Và mọi hoạt động được thực hiện bởi các ứng dụng web có thể có khả năng gây hại theo một cách nào đó.
Một ví dụ phổ biến là SQL Injection. Các cuộc tấn công DOS và vô vàn ví dụ khác.
Trong khi đó..
Các lập trình viên thường đánh giá thấp tính bảo mật, khiến hệ thống của họ dễ bị tấn công bởi các loại tấn công khác nhau.
Các lỗi bảo mật phổ biến nhất mà tôi đã thấy là về xác thực đầu thông tin đầu vào.
Đó là: Kiểm tra, Xác thực và Làm sạch dữ liệu từ chuỗi truy vấn (cũng như các nguồn khác, bao gồm cơ sở dữ liệu, tệp cục bộ và tài nguyên từ xa).
Các cuộc tấn công bằng SQL Injection cũng rất phổ biến. Trên thực tế, chúng vẫn là rủi ro bảo mật web số 1 trong năm 2017.
Bạn có thể xem thêm báo cáo 10 Rủi ro bảo mật ứng dụng Web quan trọng nhất của OWASP tại đây
Thật không may, đánh giá thấp các vấn đề bảo mật là một thói quen xấu rất phổ biến của các lập trình viên.
HÃY DÀNH THÊM CHÚT THỜI GIAN CHO BẢO MẬT!
Để bỏ thói quen xấu này, hãy tự hỏi mình câu hỏi này:
Tôi có biết chính xác điều gì xảy ra khi trang web của tôi nhận được bất kỳ đầu vào nào từ người dùng không?
Tôi có chắc chắn 100% rằng mọi thứ sẽ hoạt động tốt và hệ thống của tôi sẽ an toàn, cho dù ứng dụng được sử dụng bởi các khách hàng từ xa?
Ứng dụng của bạn sẽ chỉ được bảo mật khi câu trả lời của bạn là Có.
5: Lập trình mà không quan tâm đến khả năng mở rộng
Lập trình mà không quan tâm đến khả năng mở rộng
Thói quen xấu cuối cùng là bỏ qua khả năng mở rộng khi lập trình.
Điều này có nghĩa là: Không quan tâm đến việc ứng dụng của bạn sẽ hoạt động tốt như thế nào khi nó tiếp tục phát triển.
Một ứng dụng có thể hoạt động tốt khi phục vụ 10 người dùng, khi tìm nạp 10 mục từ cơ sở dữ liệu hoặc khi cung cấp dữ liệu JSON cho 10 máy khách từ xa.
Nhưng…
Nó vẫn hoạt động tốt với 100, 1.000, 10.000 người dùng chứ?
Nó sẽ vẫn hoạt động tốt khi cơ sở dữ liệu sẽ chứa 10.000 mục hay khi các máy khách từ xa truy xuất dữ liệu JSON gấp 100 lần?
Cơ sở dữ liệu sẽ hỗ trợ khối lượng công việc đó?
Thời gian đáp ứng vẫn sẽ được chấp nhận? Và mức tiêu hao bộ nhớ hệ thống sẽ tăng bao nhiêu?
Hiện nay:
Bạn không cần phải viết mã có thể mở rộng 1000x lần ngay từ đầu.
Có thể trang web của bạn không cần mở rộng qui mô cỡ đó.
Tuy nhiên, sẽ là một sai lầm nếu không nghĩ về khả năng mở rộng.
Trên thực tế, một thói quen xấu của nhiều lập trình viên là tạo ra các trang web, các ứng dụng mà chỉ hoạt động tốt trong các tình huống hiện tại, mà không tự hỏi liệu ứng dụng của họ có tiếp tục hoạt động tốt trong tương lai hay không.
Làm thế nào để bạn tránh thói quen xấu này?
Hãy thêm một bài kiểm tra khả năng mở rộng trong giai đoạn kiểm thử / gỡ lỗi của bạn.
Chạy ứng dụng của bạn bằng cách sử dụng 10, 100 lần hoặc 10.00 lần tập dữ liệu bạn đã sử dụng trong giai đoạn lập trình và xem nó diễn ra như thế nào.
Bộ dữ liệu này có thể là một bộ cơ sở dữ liệu của các mục, số lượng người dùng, v.v.
SUY NGHĨ VỀ KHẢ NĂNG MỞ RỘNG TỪ ĐẦU!
Xem xét một số số liệu về khả năng mở rộng để kiểm tra xem trang web của bạn có còn hoạt động tốt không, bao gồm:
- Thời gian tải
- Tiêu hao bộ nhớ hệ thống
- Dấu vết cơ sở dữ liệu
Lời kết về lời khuyên giúp tránh các thói quen xấu khi lập trình
Trong bài đăng này, bạn đã tìm hiểu về 5 thói quen xấu của các Lập trình viên và các lời khuyên để tránh chúng.
Học Lập trình PHP chuẩn, tránh 5 thói quen xấu tại NIIT - ICT Hà Nội ngay!
Tôi đã thấy hoặc thậm chí tự mình trải nghiệm những thói quen xấu này trong quá trình làm việc và tôi biết chúng có thể gây ra thiệt hại lớn.
Thế còn bạn?
Bạn có biết bất kỳ thói quen xấu nào khác mà chúng ta nên tránh không?
Chia sẻ suy nghĩ của bạn trong phần bình luận bên dưới.
Alex
HỌC VIỆN ĐÀO TẠO CNTT NIIT - ICT HÀ NỘI
Dạy học Lập trình chất lượng cao (Since 2002). Học làm Lập trình viên. Hành động ngay!
Đc: Tầng 3, 25T2, N05, Nguyễn Thị Thập, Cầu Giấy, Hà Nội
SĐT: 02435574074 - 0914939543 - 0353655150
Email: hello@niithanoi.edu.vn
Website: https://niithanoi.edu.vn
Fanpage: https://facebook.com/NIIT.ICT/
Top comments (0)