Mã spaghetti là gì

Mã spaghetti — là một phép ẩn dụ để mô tả mã có cấu trúc giống như một đĩa spaghetti: các sợi riêng lẻ (khối logic) bị rối, dính vào nhau và không thể tách rời. Trong mã như vậy, không thể phân tách các lớp, module hay thành phần — mọi thứ đều bị trộn lẫn trong một khối lớn.

Không giống mã xấu, có thể chỉ đơn giản là bất cẩn, mã spaghetti là một vấn đề kiến trúc cơ bản. Ngay cả mã được định dạng hoàn hảo với tên biến tốt cũng có thể là mã spaghetti nếu kiến trúc của nó hỗn loạn. Vấn đề nằm ở cấp độ cấu trúc chương trình, không phải phong cách viết.

Theo IEEE (2022), khoảng 35% tất cả các lỗi trong các dự án lớn là do cấu trúc mã rối rắm gây ra, không phải do lỗi logic của lập trình viên. Lập trình viên mắc lỗi không phải vì họ hiểu sai nhiệm vụ, mà vì họ không thể theo dõi luồng thực thi trong mã spaghetti.

Sự khác biệt chính với các phản mẫu khác

Nếu mã xấu là mã kém ở quy mô một hàm hay tệp tin, thì mã spaghetti là kiến trúc kém ở quy mô toàn bộ ứng dụng. Mì có thể bao gồm các hàm được viết tốt riêng lẻ, nhưng sự tương tác của chúng là hỗn loạn và không thể dự đoán.

Lịch sử thuật ngữ và thời đại goto

Thuật ngữ “mã spaghetti” xuất hiện vào những năm 1970 cùng với sự chỉ trích câu lệnh goto. Trong các ngôn ngữ lập trình đầu tiên (BASIC, FORTRAN, COBOL), goto là cách chính để điều khiển luồng thực thi. Một chương trình là một chuỗi các dòng được đánh số, và goto cho phép nhảy đến bất kỳ dòng nào. Điều này tạo ra một “mói rối” các bước nhảy không thể tháo gỡ.

Năm 1968, Edsger Dijkstra đã công bố bức thư nổi tiếng “Go To Statement Considered Harmful”, đánh dấu sự khởi đầu của kỷ nguyên lập trình cấu trúc. Dijkstra đã chứng minh rằng bất kỳ thuật toán nào cũng có thể được triển khai mà không cần goto, chỉ sử dụng ba cấu trúc: tuần tự, rẽ nhánh (if) và vòng lặp (while). Điều này trở thành nền tảng của lập trình hiện đại.

Lập trình cấu trúc không loại bỏ hoàn toàn vấn đề. Mã spaghetti đã chuyển lên một cấp độ mới — thay vì goto vật lý, các nhà phát triển bắt đầu tạo ra “goto” logic: biến toàn cục, callback hell trong JavaScript, chuỗi gọi phức tạp và các phụ thuộc ngầm giữa các thành phần. Vấn đề vẫn còn, chỉ hình thức thay đổi.

Các dạng hiện đại của goto

Callback hell trong JavaScript, Promise lồng nhau sâu, async/await không xử lý lỗi, các sự kiện không ai hiểu ai hoặc khi nào kích hoạt — tất cả đều là các biến thể hiện đại của mã spaghetti. Phản mẫu vẫn sống và phát triển, chỉ là bây giờ nó không sử dụng câu lệnh goto.

Dấu hiệu của mã spaghetti trong dự án

Thiếu các lớp — dấu hiệu đầu tiên và chính. Trong mã spaghetti, logic kinh doanh, thao tác cơ sở dữ liệu, đánh dấu HTML và giao tiếp mạng đều bị trộn lẫn trong một tệp duy nhất hoặc thậm chí một phương thức. Thay đổi một truy vấn cơ sở dữ liệu có thể phá vỡ hiển thị giao diện vì mã của các lớp này không được phân tách.

Biến toàn cục và singleton — dấu hiệu thứ hai rõ ràng. Khi trạng thái ứng dụng được lưu trữ trong các đối tượng toàn cục, luồng thực thi trở nên không thể dự đoán. Bất kỳ hàm nào cũng có thể thay đổi trạng thái toàn cục, và việc theo dõi nơi nào và khi nào điều này xảy ra là gần như không thể.

God class và god function — dấu hiệu thứ ba. Một lớp với hơn 2000 dòng xử lý logic kinh doanh, hiển thị và thao tác dữ liệu — đó là mã spaghetti điển hình. Một hàm nhận 10 tham số và làm 5 việc khác nhau — cũng là spaghetti.

Chẩn đoán qua kiểm thử

Nếu bạn không thể viết kiểm thử đơn vị cho một hàm mà không tạo 15 đối tượng giả — đó là mã spaghetti. Nếu kiểm thử một module đơn lẻ đòi hỏi khởi động toàn bộ cơ sở hạ tầng ứng dụng — đó là mã spaghetti. Không thể kiểm thử là một chỉ báo khách quan của kiến trúc rối rắm.

Tại sao mã mì xuất hiện

Thiếu thiết kế kiến trúc — nguyên nhân phổ biến nhất. Khi một nhóm bắt đầu viết mã mà không có kế hoạch, chọn kiến trúc “trên đường đi”, kết quả chắc chắn sẽ biến thành spaghetti. Mỗi tính năng mới được thêm vào nơi “thuận tiện ngay bây giờ”, không phải nơi nó thuộc về một cách logic.

Phát triển tiến hóa — nguyên nhân thứ hai. Một dự án bắt đầu như một tập lệnh nhỏ, sau đó phát triển các tính năng, sau đó trở thành ứng dụng, và sau đó là một khối đơn nhất. Trong khi đó, kiến trúc không được xem xét lại. Những gì hoạt động cho 100 dòng mã trở thành thảm họa cho 100.000 dòng.

Vi phạm các nguyên tắc SOLID — nguyên nhân thứ ba. Đặc biệt là nguyên tắc trách nhiệm duy nhất (S) và nguyên tắc đảo ngược phụ thuộc (D). Khi một lớp chịu trách nhiệm về mọi thứ, các phụ thuộc cứng nhắc và các module được liên kết chặt chẽ — bạn sẽ có mã spaghetti.

Yếu tố thời gian

Thời hạn và văn hóa hotfix — chất xúc tác cho mã spaghetti. Khi “cần có vào hôm qua”, các nhà phát triển chèn mã vào vị trí có sẵn đầu tiên mà không nghĩ đến kiến trúc. Mười hotfix như vậy — và kiến trúc ứng dụng bị phá hủy.

Hậu quả của mã spaghetti

Hậu quả chính — mất kiểm soát cơ sở mã. Các nhà phát triển không còn hiểu ứng dụng hoạt động như thế nào tổng thể. Một thay đổi ở một nơi phá vỡ một nơi khác dường như không liên quan. Mỗi bản vá tạo ra hai lỗi mới. Nhóm rơi vào trạng thái “sợ thay đổi”.

Năng suất của nhóm giảm theo cấp số nhân. Microsoft Research (2023) chỉ ra rằng thời gian thêm tính năng mới trong mã spaghetti tăng theo hàm bình phương so với kích thước cơ sở mã. Đối với kiến trúc sạch, sự tăng này là tuyến tính. Sự khác biệt trở nên nghiêm trọng ở 50.000+ dòng mã.

Bảo mật — một nạn nhân khác. Trong mã spaghetti, rất dễ bỏ sót một ngoại lệ không được xử lý, xác thực đầu vào không đúng hoặc rò rỉ dữ liệu. Kiểm toán bảo mật trong dự án có kiến trúc rối rắm gần như không thể thực hiện được — tìm tất cả các nơi sử dụng đầu vào của người dùng là bất khả thi.

Tác động đến nhóm

Tỷ lệ nghỉ việc trong các dự án có mã spaghetti cao hơn trung bình. Các nhà phát triển giàu kinh nghiệm rời đi vì họ không muốn làm việc với “mì”. Nhân viên mới không thể hiểu mã và rời đi trong những tháng đầu tiên. Dự án mất đi chuyên môn, điều này càng làm xấu đi chất lượng mã — một vòng luẩn quẩn.

Cách tái cấu trúc mã spaghetti

Thứ nhất — bắt đầu bằng cách phân tách các lớp. Chia mã thành ba cấp độ: trình bày (UI, controller), logic kinh doanh (dịch vụ, trường hợp sử dụng) và truy cập dữ liệu (kho lưu trữ, DAO). Ngay cả phân tách một phần cũng cải thiện ngay cấu trúc và làm cho mã có thể kiểm thử.

Thứ hai — triển khai dependency injection. Thay thế việc tạo trực tiếp các phụ thuộc bằng cách truyền chúng qua hàm tạo hoặc tham số. Điều này phá vỡ các kết nối cứng nhắc giữa các thành phần và cho phép kiểm thử từng module một cách riêng lẻ.

Thứ ba — trích xuất god class và god function. Chia chúng thành các lớp và phương thức nhỏ với một trách nhiệm duy nhất. Sử dụng mẫu Facade để đơn giản hóa các hệ thống con phức tạp. Hãy nhớ: một lớp 20 dòng rõ ràng hơn một lớp 2000 dòng.

// spaghetti — mọi thứ trong một phương thức
function handleRequest(req, res) {
  const db = new Database("mysql://...");
  const user = db.query("SELECT * FROM users WHERE id =" + req.params.id);
  let html = "";
  html += "
" + user.name + "
";
  html += "
Balance: " + user.balance + "
";
  html += "";
  res.send(html);
}

// kiến trúc sạch — các lớp riêng biệt
class UserController {
  constructor(userService) {
    this.userService = userService;
  }

  async getUser(req, res) {
    const user = await this.userService.findById(req.params.id);
    res.json(new UserResponse(user));
  }
}

class UserService {
  constructor(userRepository) {
    this.userRepository = userRepository;
  }

  async findById(id) {
    return await this.userRepository.findById(id);
  }
}

Chiến lược tái cấu trúc: phương pháp phẫu thuật

Đừng cố gắng viết lại toàn bộ cơ sở mã cùng một lúc — đó là thất bại chắc chắn. Chọn một module, viết các kiểm thử đặc tả (characterization tests) ghi lại hành vi hiện tại, và chỉ sau đó mới tái cấu trúc. Dần dần, từng module một, bạn sẽ tháo gỡ spaghetti.

Phòng ngừa mã mì

Lập kế hoạch kiến trúc — nền tảng của phòng ngừa. Trước khi bắt đầu phát triển, hãy phê duyệt một phong cách kiến trúc: MVC, MVVM, Clean Architecture, VIPER hoặc khác. Viết một ADR (Architecture Decision Record) giải thích lựa chọn. Yêu cầu tuân thủ kiến trúc trong quá trình xem xét mã.

Nguyên tắc đảo ngược phụ thuộc (DIP) — một công cụ mạnh mẽ chống lại mã spaghetti. Các module cấp cao không nên phụ thuộc vào các module cấp thấp. Cả hai nên phụ thuộc vào sự trừu tượng. Dependency Injection là triển khai thực tế của nguyên tắc này.

Kiểm thử — phòng ngừa tốt nhất. Nếu bạn viết kiểm thử trước mã (TDD), bạn chắc chắn sẽ thiết kế các thành phần có liên kết lỏng lẻo. Mã kiểm thử được là mã có cấu trúc tốt. Mã không thể kiểm thử hầu như luôn là mã spaghetti.

• Kiến trúc trước mã: phê duyệt sơ đồ lớp và phụ thuộc
• Dependency Injection là mẫu liên kết chính
• TDD hoặc ít nhất là độ phủ kiểm thử cao
• Xem xét mã với kiểm tra kiến trúc, không chỉ phong cách
• Tái cấu trúc thường xuyên là một phần của quy trình phát triển

Công cụ chống mã spaghetti

SonarQube — theo dõi độ phức tạp cyclomatic, độ sâu kế thừa, kích thước phương thức. JDepend (Java) — đo lường các phụ thuộc giữa các gói. PhpMetrics — cung cấp chỉ số bảo trì cho các dự án PHP. Giám sát các chỉ số trong CI/CD — ngăn chặn mì xuất hiện thay vì chống lại chúng sau khi đã xảy ra.