Nguyên lý

• -:

  • Cái trừu tượng không nên phụ thuộc vào những cái cụ thể mà những cái cụ thể nên phụ thuộc vào cái trừu tượng
  • Bộ nguyên lý SOLID giúp phần mềm dễ bảo trì, dễ mở rộng
  • Mẫu thiết kế (design pattern) là những giải pháp cho những vấn đề thường gặp trong lập trình mà nhiều thế hệ lập trình viên đã đúc kết và chứng minh tính hiệu quả của nó
  • Quy trình viết tài liệu
  • Người mới lập trình thường hỏi nên dùng cú pháp, thư viện, hay ngôn ngữ nào. Lập trình viên nhiều kinh nghiệm thường tập trung vào các khái niệm trừu tượng
  • Singleton hay được dùng trong các trình quản lý plugin
  • while familiarity is a perfectly fine reason, it is really a bad sign if it is the only reason
  • Đường cú pháp là những loại cú pháp giúp việc đọc dễ dàng hơn. Muối cú pháp là những loại cú pháp giúp việc viết sai trở nên khó khăn hơn

• Cấu trúc dữ liệu:

  • Mảng các vật thể và mảng các mảng
  • Dạng vật thể thường là tiện cho người, dạng mảng thường là tiện cho máy
  • Việc biến đổi dữ liệu chủ yếu là để người dùng đọc cho tiện, và để máy kiểm tra dữ liệu
  • Mặc dù mảng lưu giữ thứ tự, nhưng nhiều khi ta không quan tâm đến thứ tự đó cho lắm

• Đánh giá chất lượng:

  • Cyclomatic complexity đánh giá độ phức tạp khi viết kiểm thử. Cognitive complexity đánh giá độ phức tạp trong việc đọc
  • Có những đoạn code có cùng cyclomatic complexity nhưng lại khác cognitive complexity
  • Các lý do làm tăng cyclomatic complexity
  • Mỗi đường cơ sở trong biểu đồ dòng tương ứng với một testcase
  • Thay vì dùng số nút và cạnh để tính độ phức tạp chu trình, hãy đếm số miền bị chia ra

• Đặt tên biến, viết comment:

  • Block comment dành cho việc giải thích ý tưởng của code, viết doc. Line comment để debug hoặc hướng dẫn editor đọc code của mình (directive)
  • Bản thân việc lập trình bằng ngôn ngữ bậc cao đã là một dạng comment
  • Comment cũng có bug, nhưng không giống như code, không có chương trình nào hỗ trợ debug được nó
  • Comment có thể cho thông tin sai, nhưng code thì không
  • Hãy viết code sao cho mình khỏi comment
  • Quy ước đặt tên biến
  • Nên dùng comment để giải thích về thuật toán, các đánh đổi trong việc ra quyết định hoặc dẫn nguồn
  • Việc đặt tên không có tiền tố gì sẽ tiện khi nó thường được dùng thường xuyên ở những nơi khác, ở trong một danh sách, hoặc khi dùng để liệt kê các thuộc tính
  • Đặt tên biến, viết comment
  • Thay vì comment, hãy document. Thay vì giải thích cách code hoạt động, hãy hướng dẫn cách sử dụng nó

• Đơn nhiệm:

  • Mỗi lớp, hàm, mô đun chỉ đảm nhiệm một nhiệm vụ xác định
  • Sự couple dễ được sinh ra khi muốn xử lý các dữ liệu giống nhau về chức năng và na ná nhau về cấu trúc và cách xử lý
  • Việc chia các lệnh trong kịch bản thành các hàm nhỏ hơn sẽ giúp dễ bắt lỗi hơn
  • Tránh dùng hàm lồng để làm giảm sự couple

• Giao diện, giao thức:

  • API ổn định khác với API sẵn sàng cho việc tạo sản phẩm
  • Giao diện lập trình (programing interface) khác với giao diện người dùng (user interface)
  • Giao diện nhấn mạnh vào mô hình dữ liệu, còn giao thức nhấn mạnh vào các quy tắc và thủ tục trong quá trình truyền và trao đổi dữ liệu

• Thành phần chương trình:

  • Giao diện người dùng, logic, dữ liệu là 3 thành phần cơ bản cho một chương trình. Chúng có mục tiêu khác nhau, kỹ thuật xử lý khác nhau. Không thể trộn lẫn lộn với nhau được.
  • Model không biết đến View, View không biết đến Controller