Code tốt có nghĩa là ?

Code tốt có nghĩa là gì ? được dịch từ một bài nổi tiếng của Matsui Nobuyuki

Code tốt có nghĩa là:

• Đặt tại môi trường doanh nghiệp, Code tốt có nghĩa là “dễ đọc, dễ hiểu và dễ sửa chữa”
  • Tuy nhiên không đồng nghĩa phải giúp giảm lượng truyền tải I/O hay lượng sử dụng bộ nhớ
  • Cũng không phải giúp hệ thống hoạt động nhanh hơn
    • Tuy nhiên với các phần mềm game hay hoạt động tại môi trường đặc thù thì đặc điểm trên cũng được tính vào để đánh giá code tốt
  • Không phải code sử dụng các thủ pháp trick để giúp viết ngắn mà hệ thống vẫn hoạt động
    • Tại các cuộc thi programming, đặc điểm trên được tính là code tốt

Tại sao viết được code “tốt” lại cần thiết ?

• Tại doanh nghiệp, việc phát triển thường xuyên được làm theo nhóm.
• Cho dù là một mình phát triển đi chăng nữa, bản thân ở hiện tại và sau 3 tháng là 2 trình độ hoàn toàn khác nhau.
• Ở môi trường doanh nghiệp, code đại đa số là “được đọc” hơn là “được viết”
  • Do ở môi trường doanh nghiệp rất hay có việc về mở rộng chức năng, cho nên phải đọc tất cả những đoạn code “có vẻ” liên quan đến chỗ đó.
  • Khi xảy ra lỗi, cần phải đọc thật nhanh code liên quan đến đoạn gây lỗi.
• Cho nên điều quan trọng không phải là viết ra những đoạn code “có thể chạy được” mà là “dễ đọc và dễ hiểu”.

Phương châm cơ bản để viết được code tốt

• Cách viết để dễ đọc
• Đơn giản hoá logic
• Cấu trúc lại code（refactoring）thường xuyên
• Viết để có thể test được

Cách viết để dễ đọc

• Sử dụng tên hợp lý
  • Chọn từ rõ nghĩa thể hiện đúng điều mà variable hay function muốn làm
    • Những tên function như get hay tên variable kiểu result không thể hiện được bên trong nó có gì
    • Hãy thêm vào những từ rõ nghĩa, cung cấp thông tin
      • Ví dụ với biến chứa thông tin filesize => có thể đặt tên là uploaded_file_mb
  • Tránh dùng những từ chung chung như tmp hay buf
    • Tuy nhiên với trường hợp tên biến chỉ bó hẹp trong phạm vi một màn hình thì vẫn có thể sử dụng không sao cả.
    • Do phạm vi của các biến loop cũng bị giới hạn cho nên kiểu tên như “i” hay “j” cũng ok
  • Với các trường hợp không thể chọn được tên rõ ràng và muốn đặt tên dài, cũng có nghĩa là chưa phân chia ra được các module hợp lý
    • Ví dụ nếu muốn đặt tên là canvas_max_px, tại sao không tách ra class Canvas chứa biến instance tên là max_px?

• Tuân theo cách đặt tên và coding thích hợp
  • Hãy cố gắng tuân theo phong cách đã trở thành tiêu chuẩn đối với từng loại ngôn ngữ, hạn chế tạo ra các quy luật mới mình nghĩ ra
    • Ví dụ với Python:
      • PEP8
        • http://ift.tt/1jG4AfS
      • Google Python Style Guide
        • http://ift.tt/GSFghw
  • Indent và xuống dòng đều có ý nghĩa của nó cho nên cũng phải theo quy luật
    • Với Python, mặc dù indent không có liên quan trực tiếp tới control structure, vẫn phải ý thức khi sử dụng

• Chú trọng tính thống nhất cho vẻ ngoài
  • Ví dụ
    • Trường hợp có nhiều function lấy chung một variable làm argument, cho chung một thứ tự
    • Nếu định nghĩa variable mang ý nghĩa giống nhau tại nhiều module, cho tên giống nhau
  • Làm sao để người đọc không bị rơi tình trạn như: “Quái, cái hồi trước có phải thế này không nhỉ ?”

• Hạn chế việc tự viết
  • Sử dụng tối đa các chức năng thông dụng hay đã được đóng library sẵn với mỗi ngôn ngữ
    • Các xử lý tìm kiếm hay sắp xếp hầu hết đều được cung cấp code chạy rất nhanh và an toàn từ các dòng xử lý ngôn ngữ
    • Những chức năng mà ai cũng muốn như xử lý chuỗi string.. hầu hết đều được cung cấp sẵn. Với Java là apache commons, Ruby thì là active support
  • Nên đọc qua không chỉ về specs ngôn ngữ mình cần sử dụng, mà cả về specs những library chính cũng như function được cung cấp.

• Thêm comment thích hợp
  • Không ghi những comment vô nghĩa kiểu như “đây là quy định của dự án」
  • Comment về tư tưởng thiết kế và ý đồ tại sao implement method và class đó
    • Cái này vốn được tạo ra để làm gì？
    • Tại sao lại chọn logic này？Có cách thức nào khác không？
  • Comment những chỗ mình cảm thấy mơ hồ
    • Ví dụ
      • Với logic này cũng có thể chạy được tuy nhiên lượng cần tính toán với data sẽ là O(n^2)
      • Do là destructive method、internal data sẽ bị thay đổi sau khi được gọi dù chỉ 1 lần
  • Không comment những đoạn code nhìn cái là hiểu ý nghĩa
    • Những đoạn code phải comment về thứ tự xử lý để hiểu => bị coi là code không tốt

Đơn giản hoá logic