Minh họa cho YAGNI
Law #5 Thiết kế

YAGNI

YAGNI (You Aren't Gonna Need It)

Đừng thêm tính năng, abstraction hay cấu hình khi nhu cầu thực tế vẫn chưa xuất hiện.

Nguồn tham khảo: Laws of Software Engineering

Tổng quan

YAGNI khuyên không viết code cho tính năng mới chỉ được dự đoán. Nếu nhu cầu chưa thật sự xuất hiện, hook, flag, extension point hoặc abstraction làm sẵn thường chỉ tăng chi phí bảo trì.

Ý chính

  • Tập trung vào yêu cầu hiện tại thay vì xây trước các khả năng "có thể sau này cần".
  • Dự đoán tương lai quá sớm dễ dẫn đến over-engineering và thiết kế tổng quát sai hướng.
  • YAGNI dựa vào phát triển lặp: làm lời giải nhỏ đủ dùng, rồi mở rộng khi có dữ liệu thật.

Ví dụ từ nguồn

Nếu app chỉ cần export JSON, hãy làm JSON rõ ràng trước thay vì dựng sẵn framework xuất XML, YAML và nhiều format khác.

Nếu feature chưa cần bật tắt bằng cấu hình, thêm config flag chỉ để phòng xa thường làm test matrix và logic phức tạp hơn.

Nguồn gốc

YAGNI gắn với Extreme Programming cuối thập niên 1990 và được Ron Jeffries quảng bá như một nguyên tắc triển khai khi thật sự cần, không phải khi chỉ tưởng tượng sẽ cần.

Lưu ý khi áp dụng

YAGNI không phải giấy phép viết cẩu thả. Bạn cần test và khả năng refactor đủ tốt để thêm phần bị trì hoãn khi nhu cầu thật xuất hiện.

← Quay lại danh sách 56 luật