4 Dấu Hiệu Thiết Kế Phần Mềm Tệ — Và Cách Khắc Phục Từng Cái

Rigidity là xu hướng phần mềm trở nên khó thay đổi, dù chỉ là những chỉnh sửa nhỏ nhất. Một hệ thống bị coi là cứng nhắc khi một thay đổi ở module A kéo theo hàng loạt thay đổi bắt buộc ở các module B, C, D phụ thuộc vào nó.

Nguyên nhân: Thường là do excessive coupling — mọi thứ bị gắn kết quá chặt đến mức bạn không thể di chuyển một phần mà không ảnh hưởng đến toàn bộ hệ thống.

Ví dụ thực tế: Bạn có một class OrderProcessor với một khối switch khổng lồ để tính phí vận chuyển. Nếu là "UPS" thì làm X, "FedEx" thì làm Y. Khi cần thêm "DHL", bạn buộc phải sửa trực tiếp vào class đó — rồi recompile, retest toàn bộ module đơn hàng.

Fragility là xu hướng phần mềm bị hỏng ở nhiều nơi mỗi khi có một thay đổi. Khác với Rigidity, vấn đề ở đây không phải là nỗ lực thực hiện thay đổi, mà là sự thiếu kiểm soát đối với các hiệu ứng phụ ngoài ý muốn.

Nguyên nhân: Xuất phát từ các hidden dependencies — phụ thuộc ẩn — hoặc logic quá đan xen khiến các module biết quá nhiều về cơ chế nội bộ của nhau.

Ví dụ thực tế: Bạn có một biến toàn cục hoặc Singleton lưu "System Configuration." Một lập trình viên đổi định dạng ngày tháng trong cấu hình đó để phục vụ một report cụ thể. Đột nhiên, module Payroll ngừng xử lý thanh toán — vì nó kỳ vọng định dạng cũ. Hệ thống bị vỡ ở chỗ hoàn toàn không liên quan đến thay đổi ban đầu.

Immobility là tình trạng phần mềm không thể được tái sử dụng ở các dự án khác, thậm chí ở các phần khác của cùng một dự án. Điều này xảy ra khi thiết kế bị gắn chặt với môi trường đến mức chi phí tách một tính năng ra còn tốn kém hơn viết lại từ đầu.

Nguyên nhân: Thiết kế không tách biệt business rules khỏi implementation details — như database, framework hay giao diện người dùng.

Ví dụ thực tế: Bạn viết một thuật toán xuất sắc để validate mã số thuế hoặc CMND. Nhưng thuật toán đó nằm bên trong class UserRegistrationForm — class này kế thừa từ một thư viện UI như React hoặc Android SDK và gọi thẳng vào database để kiểm tra trùng lặp.

Viscosity là sự cản trở mà hệ thống tạo ra khi bạn cố gắng làm mọi thứ theo cách đúng đắn. Nó tồn tại dưới hai hình thức:

Software Viscosity: Thêm một "hack" tạm thời dễ hơn nhiều so với việc giữ kiến trúc sạch đúng thiết kế ban đầu.

Environment Viscosity: Môi trường phát triển quá chậm hoặc kém hiệu quả — compile lâu, test chạy hàng giờ — khiến lập trình viên bị cám dỗ bỏ qua quy trình chính thức.

Tổng Kết — Những Điều Cần Ghi Nhớ

Bốn dấu hiệu trên — Rigidity, Fragility, Immobility và Viscosity — không chỉ là khái niệm lý thuyết. Chúng là những "mùi hôi" thực sự báo hiệu hệ thống của bạn đang cần được chú ý và cải thiện.

Điều quan trọng cần nhớ: thiết kế tệ không phải bản án chung thân. Nhận diện được những dấu hiệu này là bước đầu tiên để refactor và tiến về phía một kiến trúc incremental, lành mạnh và bền vững hơn.

Bạn đang gặp phải dấu hiệu nào trong số này ở dự án hiện tại? Dấu hiệu nào bạn thấy khó xử lý nhất? Chia sẻ trong phần bình luận — tôi đọc và trả lời tất cả.