Làm thế nào để viết hàm 'chuẩn chỉnh' như dân chuyên nghiệp? 3 bí kíp bạn cần biết!
Lê Lân
0
3 Nguyên Tắc Viết Hàm Dễ Hiểu và Dễ Bảo Trì Trong Lập Trình
Mở Đầu
Việc viết code sạch, dễ hiểu và dễ bảo trì luôn là thách thức với mọi lập trình viên, đặc biệt khi dự án ngày càng phức tạp. Một trong những cách hiệu quả nhất để giảm độ phức tạp của phần mềm là tập trung vào cách viết hàm (function) – đơn vị cơ bản nhất trong lập trình hướng đối tượng (OOP).
Trong bài viết này, tôi sẽ chia sẻ ba nguyên tắc quan trọng giúp bạn viết hàm ngắn gọn, rõ ràng và dễ bảo trì, dựa trên kinh nghiệm thực tế và phong cách lập trình Ruby mà tôi theo đuổi. Bạn sẽ thấy cách tối ưu từng hàm sao cho mã nguồn không chỉ hoạt động hiệu quả mà còn dễ dàng thay đổi, mở rộng trong tương lai.
1. Giữ Hàm Ngắn Gọn (Keep It Short)
Tại Sao Nên Giữ Hàm Ngắn?
Trong Ruby, việc giữ hàm ngắn là chuẩn mực giúp mã nguồn trở nên dễ đọc và dễ quản lý. Một hàm ngắn sẽ:
Giúp bạn đọc hiểu chức năng nhanh chóng
Giảm thiểu lỗi khi sửa đổi
Dễ dàng tái sử dụng và kiểm thử
Quy Tắc Thực Tiễn
Tôi từng đặt giới hạn mềm là từ 10–12 dòng cho mỗi hàm khi làm tech lead. Tuy nhiên, mức này có thể gây khó khăn cho nhóm mới hoặc chậm tiến độ. Một con số hợp lý hơn và được áp dụng rộng rãi là:
Hàm được chia nhỏ, mỗi đoạn thực hiện một nhiệm vụ duy nhất, rất dễ đọc và bảo trì.
2. Một Hàm, Một Lý Do Thay Đổi (Single Responsibility Principle)
Nguyên Tắc
Một hàm chỉ nên có một lý do để thay đổi, tức là thực hiện một nhiệm vụ duy nhất. Nếu một hàm vừa thực hiện tính toán, vừa gửi email, vừa ghi log… tức là hàm đó gánh quá nhiều trách nhiệm.
Cách Kiểm Tra
Hãy tự hỏi bản thân:
“Hàm này làm gì?”
Nếu câu trả lời có từ “và” hoặc nhiều hơn một hành động, bạn nên tách hàm đó thành các hàm nhỏ hơn.
Lợi Ích
Giảm rủi ro khi thay đổi một chức năng
Dễ dàng tái sử dụng lại từng phần
Mỗi phần có thể test riêng rẽ, tăng chất lượng code
Lưu ý: Việc tuân thủ nguyên tắc này không chỉ giúp code sạch hơn mà còn tăng tốc độ phát triển dự án về lâu dài.
3. Duy Trì Mức Độ Trừu Tượng Nhất Quán (Consistent Level of Abstraction)
Tại Sao Quan Trọng?
Mỗi hàm nên hoạt động ở một “mức độ trừu tượng” nhất định, tránh việc trộn lẫn chi tiết cài đặt thấp (ví dụ: truy vấn database) với hành động nghiệp vụ cao cấp (ví dụ: xử lý thanh toán, gửi thông báo). Khi không giữ nguyên tắc này, người đọc sẽ phải liên tục chuyển đổi ngữ cảnh trong đầu, dẫn đến khó hiểu và dễ nhầm lẫn.
Ví Dụ Phân Tích
Ở đoạn code trước khi refactor, hàm process_payment vừa truy cập database, gọi API bên ngoài, xử lý nghiệp vụ, gửi thông báo, và kích hoạt job nền trong một đoạn code dài. Điều này làm cho hàm trở nên quá tải thông tin.
Sau refactor, hàm chính chỉ mang tính tổ chức (orchestration), còn các chi tiết nhỏ đều được tách ra thành hàm riêng biệt với cùng một cấp độ trừu tượng. Ví dụ:
process_payment — Cấp độ cao, điều phối luồng xử lý
charge_order — Cấp độ trung bình, xử lý thanh toán
Các hàm handle_successful_payment, handle_failed_payment — Cấp độ nghiệp vụ
Kết Quả
Code trở nên dễ hiểu hơn, thân thiện với người đọc mới, và giảm khả năng lỗi phát sinh do nhầm lẫn.
Kết Luận
Qua ba nguyên tắc đơn giản nhưng vô cùng hiệu quả:
Giữ hàm ngắn gọn, tối đa 20 dòng
Một hàm chỉ nên có một lý do để thay đổi
Duy trì mức độ trừu tượng cố định trong mỗi hàm
bạn sẽ cải thiện được chất lượng mã nguồn, giúp code dễ hiểu và dễ bảo trì. Đây cũng là nền tảng để phát triển phần mềm bền vững và mở rộng được tốt hơn.
Hãy thử áp dụng những nguyên tắc này cho các dự án tiếp theo và so sánh hiệu quả trước – sau nhé! Nếu bạn có thêm kinh nghiệm hoặc nguyên tắc riêng, đừng ngần ngại chia sẻ để chúng ta cùng học hỏi.
Tham Khảo
Martin Fowler, Refactoring: Improving the Design of Existing Code, Addison-Wesley Professional, 2018.
Robert C. Martin, Clean Code: A Handbook of Agile Software Craftsmanship, Prentice Hall, 2008.