Có một sự thật mà lập trình viên nào làm lâu năm cũng thấm: thời gian ta đọc code nhiều hơn rất nhiều so với thời gian viết code. Mỗi lần sửa lỗi, thêm tính năng hay review cho đồng nghiệp, ta phải hiểu được đoạn code hiện có trước đã. Clean Code không phải là viết code "đẹp" cho vui mắt, mà là viết code sao cho người đọc tiếp theo, rất có thể là chính bạn vài tháng sau, hiểu được nhanh nhất. Bài viết này tập trung vào hai mảng mang lại hiệu quả rõ rệt nhất: đặt tên và tổ chức hàm.

Đặt tên: tên tốt thay cho cả đoạn comment

Tên phải nói lên ý định

Một cái tên tốt trả lời được câu hỏi: biến này chứa gì, hàm này làm gì, và vì sao nó tồn tại. So sánh hai đoạn sau:

// Khó hiểu
const d = 7;
if (u.t > d) send(u);
 
// Rõ ràng
const TRIAL_PERIOD_DAYS = 7;
if (user.daysSinceSignup > TRIAL_PERIOD_DAYS) sendUpgradeReminder(user);

Đoạn thứ hai dài hơn một chút nhưng gần như không cần giải thích gì thêm. Các "con số ma thuật" như 7 được thay bằng hằng số có tên, nhờ đó khi chính sách đổi thành 14 ngày, bạn biết chính xác cần sửa ở đâu.

Một số quy tắc đặt tên thực tế

  • Biến và thuộc tính là danh từ: invoice, totalAmount, activeUsers.
  • Hàm là động từ hoặc cụm động từ: calculateTax, fetchOrders, validateEmail.
  • Biến boolean nên đọc như một câu hỏi: isActive, hasPermission, canEdit, shouldRetry.
  • Tránh viết tắt khó đoán: customerAddress thay vì custAddr; trừ những từ viết tắt phổ biến như id, url, html.
  • Một khái niệm, một từ: nếu đã dùng fetch cho việc lấy dữ liệu từ API thì đừng lẫn lộn với get, retrieve, load cho cùng loại thao tác.
  • Độ dài tên tỷ lệ với phạm vi: biến đếm trong vòng lặp ba dòng có thể là i, nhưng biến dùng xuyên suốt một module cần tên đầy đủ.
  • Dùng thuật ngữ của nghiệp vụ: nếu đội kinh doanh gọi là "đơn hàng nháp" thì code nên có draftOrder, giúp lập trình viên và người làm nghiệp vụ nói cùng một ngôn ngữ.

Với team Việt Nam, một câu hỏi hay gặp là có nên đặt tên bằng tiếng Việt không dấu. Lời khuyên chung là dùng tiếng Anh cho tên trong code để thống nhất với thư viện và tài liệu, còn comment và tài liệu nghiệp vụ có thể dùng tiếng Việt. Quan trọng nhất vẫn là cả nhóm thống nhất một quy ước.

Tổ chức hàm: nhỏ, tập trung và dễ đoán

Mỗi hàm làm một việc

Nếu bạn cần dùng chữ "và" để mô tả hàm, ví dụ "kiểm tra dữ liệu và lưu database và gửi email", đó là dấu hiệu nên tách hàm. Không có con số cứng cho độ dài lý tưởng; tiêu chí tốt hơn là: tên hàm có mô tả trọn vẹn những gì nó làm hay không. Khi một đoạn code cần một dòng comment để giải thích nó làm gì, thường bạn có thể tách đoạn đó thành hàm riêng với tên chính là nội dung của comment.

async function registerUser(input) {
  const data = validateRegistration(input);
  const user = await createUser(data);
  await sendWelcomeEmail(user);
  return user;
}

Hàm cấp cao đọc như một mục lục, mỗi dòng là một bước ở cùng mức trừu tượng. Ai cần chi tiết thì đi sâu vào từng hàm con.

Giữ số tham số ít

Hàm nhận năm, sáu tham số vừa khó nhớ thứ tự vừa dễ truyền nhầm. Khi số tham số vượt quá ba, hãy cân nhắc gom chúng vào một object với tên trường rõ ràng. Đặc biệt tránh tham số boolean kiểu createReport(data, true), vì người đọc không biết true nghĩa là gì. Hãy tách thành hai hàm hoặc dùng object tùy chọn như { includeDrafts: true }.

Thoát sớm thay vì lồng nhiều tầng

Những khối if lồng ba, bốn tầng là kẻ thù của sự dễ đọc. Kỹ thuật guard clause, tức kiểm tra điều kiện lỗi và return sớm, giúp luồng chính nằm thẳng hàng:

function applyDiscount(order, coupon) {
  if (!coupon) return order;
  if (coupon.isExpired) throw new Error("Mã giảm giá đã hết hạn");
  if (order.total < coupon.minOrder) return order;
  return { ...order, total: order.total - coupon.amount };
}

Hạn chế tác dụng phụ bất ngờ

Một hàm tên getUser thì không nên âm thầm cập nhật thời gian đăng nhập cuối. Nếu hàm thay đổi trạng thái bên ngoài, tên hàm phải thể hiện điều đó. Hàm thuần, tức cùng đầu vào luôn cho cùng đầu ra và không tác động gì bên ngoài, là loại dễ kiểm thử và dễ tái sử dụng nhất.

Áp dụng mà không cực đoan

Clean Code là kim chỉ nam chứ không phải luật cứng. Tách hàm quá vụn cũng khiến người đọc phải nhảy qua lại giữa hàng chục file. Hãy áp dụng quy tắc hướng đạo sinh: mỗi lần chạm vào một file, để nó sạch hơn một chút so với lúc bạn đến, như đổi một cái tên khó hiểu hay tách một hàm quá dài. Cải thiện nhỏ, đều đặn hiệu quả hơn nhiều so với một đợt "đập đi xây lại".

Kết luận

Đặt tên rõ ràng và tổ chức hàm hợp lý là hai kỹ năng có tỷ suất lợi nhuận cao nhất trong Clean Code: không cần công cụ, không tốn chi phí, nhưng giúp cả team đọc code nhanh hơn và ít lỗi hơn mỗi ngày. Hãy bắt đầu từ những thói quen nhỏ: đặt tên nói lên ý định, mỗi hàm làm một việc, thoát sớm thay vì lồng sâu. Code sạch không đến từ một lần viết hoàn hảo, mà từ việc liên tục chăm chút.

Nguồn tham khảo