Nguyên lý

• -:

  • Bộ nguyên lý SOLID giúp phần mềm dễ bảo trì, dễ mở rộng
  • 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
  • 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ó
  • 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
  • Quy trình viết tài liệu
  • 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:

  • 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
  • Mảng các vật thể và mảng các mảng
  • 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
  • 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

• Đá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ác lý do làm tăng cyclomatic complexity
  • Có những đoạn code có cùng cyclomatic complexity nhưng lại khác cognitive complexity
  • 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
  • Mỗi đường cơ sở trong biểu đồ dòng tương ứng với một testcase

• Đặ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ó thể cho thông tin sai, nhưng code thì không
  • 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ó
  • 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
  • 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ó
  • 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

• Đơ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ý
  • Tránh dùng hàm lồng để làm giảm sự couple
  • 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

• 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 và giao thức đều là những thứ các bên cần tuân thủ để sự giao tiếp được diễn ra, nhưng 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