Dự án: refactor code “bẩn”

Đây là lúc biến lý thuyết thành kỹ năng thực hành. Ba thử thách dưới đây cho mèo con một đoạn TypeScript "bẩn" thật - không phải ví dụ đơn giản hoá - và yêu cầu refactor từng bước. Mỗi thử thách có khối "Hoàn thành khi" để tự chấm.

Nguyên tắc cốt lõi xuyên suốt cả ba thử thách: refactor = giữ nguyên hành vi, đổi cấu trúc. Không có test đỡ lưng thì không biết mình có lỡ đổi hành vi không. Vì vậy, mỗi thử thách bắt đầu bằng viết characterization test cho code gốc trước khi đụng vào.

• ▸Làm trên TypeScript (hoặc JavaScript thuần nếu bạn chưa quen TS - tư duy giống nhau).
• ▸Viết characterization test TRƯỚC: chốt "code hiện đang làm gì" để refactor mạnh dạn.
• ▸Refactor TỪNG BƯỚC nhỏ, chạy test sau mỗi bước - không sửa ào một lần rồi mới test.

Hàm dưới đây tính chiết khấu và tổng tiền cho đơn hàng. Nó chạy được, nhưng vi phạm nhiều thứ đã học ở bài Hàm nhỏ và bài Đặt tên: hàm dài làm nhiều việc, lồng sâu, magic number rải khắp, tên biến viết tắt.

function calc(o: { items: { p: number; q: number }[]; vip: boolean }): number {
  let t = 0;
  for (let i = 0; i < o.items.length; i++) {
    t += o.items[i].p * o.items[i].q;
  }
  let d = 0;
  if (o.vip) {
    if (t > 1000000) {
      d = t * 0.15;
    } else if (t > 500000) {
      d = t * 0.1;
    } else {
      d = t * 0.05;
    }
  } else {
    if (t > 1000000) {
      d = t * 0.08;
    } else if (t > 500000) {
      d = t * 0.05;
    }
  }
  return t - d;
}

Yêu cầu:

• Viết ít nhất một characterization test - gọi calc() với vài đầu vào, ghi lại kết quả thực tế làm kỳ vọng.
• Dùng extract function tách thành ít nhất: một hàm tính tổng tiền hàng, một hàm tính chiết khấu - đặt tên rõ ý định.
• Thay toàn bộ magic number (0.15, 1000000...) bằng hằng số có tên giải thích ý nghĩa.
• Chạy characterization test sau khi xong - phải xanh.

Lớp dưới đây ôm đồm cả dữ liệu người dùng lẫn nghiệp vụ gửi thông báo và tạo báo cáo - điển hình của God object vi phạm SRP. Cũng là một hybrid xấu: vừa có public field như data structure, vừa có method nghiệp vụ như object - chủ đề từ bài Object vs Data Structure.

class UserManager {
  // public field lan lon voi method nghiep vu
  public name: string;
  public email: string;
  public role: string;
  public lastLogin: Date;
  public loginCount: number;
  public notificationsSent: string[] = [];

  constructor(name: string, email: string, role: string) {
    this.name = name;
    this.email = email;
    this.role = role;
    this.lastLogin = new Date();
    this.loginCount = 0;
  }

  // nghiep vu 1: kiem tra quyen truy cap
  canAccess(resource: string): boolean {
    if (this.role === 'admin') return true;
    if (resource === 'dashboard' && this.role === 'manager') return true;
    return false;
  }

  // nghiep vu 2: ghi nhat ky dang nhap
  recordLogin(): void {
    this.lastLogin = new Date();
    this.loginCount++;
    console.log(`User ${this.name} logged in at ${this.lastLogin}`);
  }

  // nghiep vu 3: gui thong bao - giao tiep he thong ngoai
  sendNotification(message: string): void {
    // gia lap gui email
    console.log(`Sending email to ${this.email}: ${message}`);
    this.notificationsSent.push(message);
  }

  // nghiep vu 4: tao bao cao - dung dinh dang rieng
  generateReport(): string {
    return `=== BAO CAO NGUOI DUNG ===\nTen: ${this.name}\nEmail: ${this.email}\nVai tro: ${this.role}\nLan dang nhap cuoi: ${this.lastLogin.toISOString()}\nTong so lan: ${this.loginCount}\nThong bao da gui: ${this.notificationsSent.length}`;
  }
}

Yêu cầu:

• Tách dữ liệu thuần thành một interface hoặc type riêng (UserData hay tương tự) - không có method.
• Tách các trách nhiệm thành ít nhất 2 lớp hoặc module rõ ràng: ví dụ lớp quản lý quyền truy cập, lớp ghi nhật ký hoạt động, và một hàm/module tạo báo cáo.
• Mỗi lớp/module mới chỉ có một lý do để thay đổi - đặt tên phản ánh đúng trách nhiệm đó.

Module dưới đây dùng thật trong một hệ thống xử lý đơn hàng giả lập. Nó chứa nhiều code smell đã học ở bài Code smell & refactoring: logic trùng lặp, dead code, catch rỗng nuốt lỗi, và trả null - vi phạm bài Xử lý lỗi sạch.

interface Order { id: string; items: { name: string; price: number }[]; status: string; }

// ham tra null khi khong tim thay
function findOrder(orders: Order[], id: string): Order | null {
  for (let i = 0; i < orders.length; i++) {
    if (orders[i].id === id) return orders[i];
  }
  return null;
}

// logic tinh tong bi sao chep y het o hai noi
function getOrderTotal(order: Order): number {
  let total = 0;
  for (const item of order.items) {
    total += item.price;
  }
  return total;
}

function printOrderSummary(order: Order): void {
  // sao chep y het getOrderTotal thay vi goi lai
  let total = 0;
  for (const item of order.items) {
    total += item.price;
  }
  console.log(`Don hang ${order.id}: ${total} VND`);
}

// catch rong - nuot loi im lang
function processOrder(orders: Order[], id: string): void {
  try {
    const order = findOrder(orders, id);
    if (order === null) return; // caller khong biet co loi
    order.status = 'processing';
    console.log(`Dang xu ly don ${order.id}`);
  } catch (e) {
    // TODO: xu ly sau
  }
}

// dead code - ham nay khong con duoc goi o dau
function legacyExportOrder(order: Order): string {
  return JSON.stringify(order);
}

// tra null thay vi mang rong
function getOrdersByStatus(orders: Order[], status: string): Order[] | null {
  const result = orders.filter((o) => o.status === status);
  if (result.length === 0) return null;
  return result;
}

Yêu cầu - làm theo thứ tự:

• Bước 0 (bắt buộc): viết characterization test cho ít nhất processOrder và getOrdersByStatus trước khi đụng vào code.
• Bước 1: xoá trùng lặp - printOrderSummary gọi lại getOrderTotal thay vì sao chép.
• Bước 2: xoá dead code (legacyExportOrder). Chạy test.
• Bước 3: sửa getOrdersByStatus trả mảng rỗng [] thay vì null.
• Bước 4: sửa catch rỗng trong processOrder - ít nhất phải log + rethrow hoặc fail rõ ràng khi không tìm thấy đơn.
• Chạy characterization test sau mỗi bước.

Bạn đã đi qua 11 bài, từ nền tảng đến tổng hợp:

• Vì sao code sạch - code đọc nhiều hơn viết; quy tắc Boy Scout.
• Đặt tên - tên rõ ý định, searchable, không gây nhiễu.
• Hàm nhỏ - một việc, một mức trừu tượng, không flag argument.
• Bình luận - giải thích "vì sao", không giải thích "cái gì".
• Định dạng - đọc như bài báo; để Prettier lo chi tiết.
• Object vs Data Structure - bất đối xứng, Luật Demeter, DTO.
• Xử lý lỗi sạch - exception, không trả null, không nuốt lỗi.
• Ranh giới (Boundaries) - bọc API ngoài sau interface của mình.
• Unit test sạch - F.I.R.S.T, AAA, tên test kể chuyện.
• Code smell & refactoring - nhận diện mùi, refactor an toàn có test.
• Thiết kế đơn giản - bốn quy tắc Kent Beck; YAGNI; cầu nối sang SOLID.

Quan trọng hơn danh sách kỹ thuật là thói quen: "code được đọc nhiều hơn viết" - mỗi lần viết là viết thư gửi cho người đọc tương lai (thường là chính mèo con sau vài tháng). Và quy tắc Boy Scout: để mỗi chỗ mình chạm vào sạch hơn một chút - không cần đại tu, chỉ cần đều đặn. Hai thói quen đó, bền hơn mọi kỹ thuật.