Khi nào không nên dùng SDD
SDD không phải thuốc chữa mọi bệnh. Có những trường hợp nó chỉ làm team chậm hơn, thêm việc hơn, tạo cảm giác “quy trình vì quy trình”. Hiểu ranh giới quan trọng không kém hiểu phương pháp.
KHÔNG nên dùng khi
- Prototype dùng một lần dưới một tuần - demo cho founder thứ Hai, chạy một lần rồi bỏ → Vibe Coding có thể là lựa chọn đúng.
- Spike kỹ thuật - mục tiêu là học (thử GraphQL Federation, vector DB). Sau khi spike chứng minh đáng làm tiếp, lúc đó viết spec cũng được.
- Script một lần dùng - migration nhỏ, report ad-hoc, batch sửa dữ liệu nội bộ.
- Side project một người - codebase nhỏ, gần như không turnover. Vài README ngắn là đủ.
- Tổ chức chưa có ai chịu trách nhiệm làm rõ nghiệp vụ - không có PO/BA/founder/customer đủ rõ để trả lời “đúng là gì” → spec dễ biến thành tranh luận nội bộ. Sửa vấn đề ownership trước, SDD sau.
NÊN dùng khi (một hoặc nhiều dấu hiệu)
- Hệ thống sẽ sống hơn 6 tháng.
- Hơn 2 dev cùng làm codebase.
- Có rule nghiệp vụ không tầm thường: tiền, hợp đồng, pháp lý, quyền truy cập, quy trình vận hành.
- Team có khả năng đổi người.
- AI đang sinh một phần đáng kể code.
- Đây là phần lõi của sản phẩm, không phải tool dùng rồi bỏ.
Quy tắc một câu
Nếu chi phí bảo trì và onboard về sau lớn hơn chi phí viết spec từ đầu, hãy cân nhắc dùng SDD.
Liên quan
- Spec-Driven Development - bức tranh tổng
- Vibe Coding - lựa chọn đúng cho prototype/spike
- Hexagonal Architecture - quy tắc “6 tháng / 2 dev / rule không tầm thường”