Có thể bạn sẽ thấy tổn thương khi đọc bài viết này, nhưng đừng lo lắng quá. Ai cũng sẽ gặp phải 1 số dấu hiệu trong đây, nhưng điều quan trọng là chúng ta không ngừng chăm chỉ để cải thiện nó. Nếu bạn không biết mình sai ở đâu, làm sao bạn có thể tìm được cách để khắc phục chúng đúng không? Nhiều khi thứ mình cần là một ai đó chỉ ra những sai lầm để còn biết đường mà sửa.

Chúng ta thường biết bản thân cần làm gì để tiến bộ, nhưng nhiều khi lại chẳng chịu làm những điều ấy. Lúc nào cũng “để sau đi”, mà “để sau” nhiều khi có nghĩa là “Không bao giờ”. Đây là một dấu hiệu tiêu biểu của một LTV lười biếng và cũng là bước đường tạo nên một LTV tồi.

Hôm qua, tôi đã đọc một bài viết rất dài và giá trị của Daryll Santos trên Github và sẽ tóm lược một số thông tin chính và quan trọng dưới đây, về 6 dấu hiệu của một LTV tồi.

1. Không hiểu mục tiêu của code

Trước khi viết code, bạn cần biết được code của mình dùng để làm gì, mục đích cụ thể ra sao. Điều này giống như chạy code trước trong đầu vậy.

Dấu hiệu: 

  1. Giữ các biến không bao giờ được sử dụng
  2. Có những Output không liên quan
  3. Gọi các function không liên quan đến mục tiêu
  4. Liên tục chạy những function vô nghĩa, chẳng hạn như save () nhiều lần, chỉ để chắc chắn
  5. Fix bug bằng cách viết code ghi đè lên mã lỗi
  6. Chuyển đổi giá trị không cần thiết. Giống như lần đầu tiên chuyển đổi một số thập phân thành một chuỗi và sau đó lại chuyển đổi chuỗi thành số thập phân

Biện pháp khắc phục:

  1. Sử dụng trình gỡ lỗi riêng của IDE
  2. Kiểm tra giá trị của các biến trước và sau khi thay đổi.

2. Kém hiểu biết về kiến trúc của ngôn ngữ

Lập trình hướng đối tượng là một mô hình lập trình, lập trình Hàm hay Khai báo cũng vậy. Chúng khác với lập trình thủ tục hoặc lập trình so sánh. Các lập trình viên thường bị bối rối khi họ chuyển từ kiến trúc này sang kiến trúc khác, và đó là điều bình thường. Nhưng dần dần, bạn phải hiểu rõ hơn về kiến trúc đó.

Dấu hiệu:

  1. Không tuân theo tiêu chuẩn OOP.
  2. (OOP) Gọi các hàm / biến không tĩnh trong các lớp không định nghĩa.
  3. (OOP) Viết nhiều lớp “XXXXManager” với tất cả các phương thức để thao tác các trường của đối tượng với một ít phương thức hoặc không có phương thức của riêng chúng.
  4. Xử lý cơ sở dữ liệu quan hệ như một kho lưu trữ đối tượng.
  5. Thực hiện tất cả các phép nối và thực thi quan hệ trong mã máy khách.
  6. Tạo nhiều phiên bản của cùng một thuật toán để xử lý các kiểu khác nhau.
  7. Đặt các giá trị riêng lẻ (trong mã mệnh lệnh) thay vì sử dụng liên kết dữ liệu.

Biện pháp khắc phục:

  1. Đây không phải vấn đề có thể giải quyết trong ngày một ngày hai. Bạn cần luyện tập, luyện tập và luyện tập nhiều hơn nữa.
  2. Đọc tài liệu. Nếu bạn không hiểu kiến trúc của ngôn ngữ hoặc các khái niệm cơ bản về OOP, hãy đầu tư thời gian để hiểu rõ hơn.
  3. Làm theo code của lập trình viên cao cấp.

3. Không tin vào code của mình

Khi logic của bạn kém, bạn sẽ nhầm lẫn và mất lòng tin vào code của chính mình.

Dấu hiệu: 

  1. Viết các function IsNull() - IsNotNull() - IsTrue(bool) - IsFalse(bool) một cách không cần thiết.
  2. Kiểm tra xem biến kiểu boolean có phải là biến khác đúng hay sai hay không.
  3. Gọi các chức năng giống nhau nhiều lần để xác nhận rằng nó thực thi.

Biện pháp khắc phục:

  1. Đừng mang những thói quen cũ không cần thiết từ một ngôn ngữ có hệ thống loại yếu.
  2. Hãy tự tin về logic của bạn. Nếu có vấn đề với logic, hãy thử logic mới.

4. Rơi vào bẫy đệ quy

Ý tưởng về đệ quy là khó nhưng không quá khó. Nhưng nhiều lập trình viên lại rất sợ đệ quy. Đệ quy sẽ làm cho code sạch hơn và hiệu quả hơn. Đệ quy giống như một cái thang. bạn chỉ cần hình dung “bạn đang ở đâu” và “đâu là cơ sở” và bạn sẽ bước lên hay bước xuống như thế nào.

Dấu hiệu:

  1. Các thuật toán lặp phức tạp cho các vấn đề có thể được giải bằng đệ quy. Giống như duyệt qua một cây hệ thống tệp.
  2. Kiểm tra điều kiện cơ sở cả trước và sau khi gọi đệ quy.
  3. Các hàm đệ quy không kiểm tra điều kiện cơ sở.
  4. Các chương trình con đệ quy nối / tổng với một biến toàn cục hoặc một biến đầu ra mang theo.

Biện pháp khắc phục:

  1. Chạy code theo nhiều bước để hiểu quy trình. Có thể xảy ra tràn ngăn xếp nhưng cũng không cần lo lắng quá.
  2. Thay đổi điều kiện cơ sở để xem kết quả đầu ra.
  3. Mục tiêu của bạn là có được sự tự tin và hoàn toàn cảm nhận được bạn đang ở đâu và bạn đang làm gì.

5. Thiếu kỹ năng nghiên cứu

Các framework và ngôn ngữ hiện đại có chiều rộng và chiều sâu tuyệt vời với các lệnh và tính năng tích hợp sẵn. Vì kiến thức quá lớn, một lập trình viên giỏi cũng thường sẽ cần vài năm để có thể học và biết cách sử dụng hết. Và họ sẽ luôn tìm kiếm một chức năng tích hợp sẵn trước khi bắt đầu triển khai chức năng của riêng họ.

Dấu hiệu: 

  1. Cố gắng tạo ra những thứ mới mà không có các cơ chế cơ bản được tích hợp sẵn trong ngôn ngữ, chẳng hạn như sevents-and-handlers hoặc biểu thức chính quy.
  2. Cố gắng tái tạo các lớp và chức năng được xây dựng trong framework
  3. Thay vì tìm kiếm và học hỏi lại đi xin code của người khác
  4. Cố chấp sử dụng kỹ thuật cũ ngay cả khi đã có kỹ thuật mới tốt hơn
  5. Thay vì tìm kiếm một giải pháp đơn giản lại làm cho mọi chuyện trở nên phức tạp bằng cách viết hầm bà lằng code

Biện pháp khắc phục:

  1. Kỹ năng nghiên cứu khó lòng có thể trau dồi chỉ trong ngày 1 ngày 2, nhưng hãy kiên trì
  2. Đừng chưa gì đã copy code khi gặp 1 vấn đề khó khăn, hãy dành thời gian tìm hiểu, đọc tài liệu kỹ càng

6. Kém hiểu biết về con trỏ

Nếu không hiểu khái niệm về con trỏ, bạn sẽ rất khó để viết các cấu trúc dữ liệu phức tạp và các API hiệu quả. Bạn sẽ tạo ra thiết kế cấu trúc dữ liệu kém và gặp nhiều lỗi.

Dấu hiệu: 

  1. Thiếu kiến thức để phân biệt giữa giá trị truyền và tham chiếu chuyển qua trong các lệnh gọi phương thức.
  2. Không thể triển khai danh sách được liên kết.
  3. Không thể tìm thấy hoặc sửa lỗi xảy ra do thực hiện sai số học trên con trỏ.
  4. Không có khả năng viết mã chèn / xóa các nút khỏi danh sách hoặc cây được liên kết mà không làm mất hoặc xóa dữ liệu.
  5. Tạo bản sao của con trỏ, thay đổi giá trị được tham chiếu qua bản sao, sau đó nghĩ rằng con trỏ gốc vẫn trỏ đến giá trị cũ.

Biện pháp khắc phục:

  1. Pointer rất dễ hiểu nhưng thường bị hiểu nhầm vì thiếu thực hành.

Kết luận

Tôi biết rằng, lập trình là một lĩnh vực rất khó. Mà thực ra, lĩnh vực nào để làm tốt cũng đều khó khăn cả. Nhưng hard work pays off, nên đừng quá nản chí. Biết mình sai là bước đầu tiên để trở nên tốt đẹp hơn. Chúc các bạn thành công và ngày một tiến bộ hơn nhé!