🪴ttuan's garden

2 min read

Những hiểu nhầm về SDD

SDD hay bị hiểu sai theo năm kiểu. Gỡ được chúng thì mới áp dụng đúng liều, tránh vừa làm vừa nghi ngờ.

1. “SDD là waterfall mới”

Không hẳn. Waterfall yêu cầu spec đầy đủ trước, code sau, ít quay lại. SDD chỉ yêu cầu spec vừa đủ để bắt đầu, rồi để spec lớn lên qua feedback. Sai thì sửa spec, học thêm rule thì thêm vào spec - nhịp vẫn là lặp và học tiếp. Xem note riêng SDD không phải Waterfall.

2. “SDD chậm hơn”

Tuần đầu chậm hơn thật, vì team phải viết BR, use case, AC và Entity Model. Nhưng tháng thứ ba mới là nơi SDD trả giá trị: onboard nhanh hơn, refactor tự tin hơn, AI regenerate an toàn hơn. Nếu dự án quá ngắn (dưới một tuần) thì không kịp thu hồi khoản đầu tư đó → lúc đó đừng dùng (Khi nào không nên dùng SDD).

3. “SDD chỉ dành cho enterprise”

Không phải. Startup ba người vẫn dùng được nếu phần họ làm có rule nghiệp vụ thật. Doanh nghiệp lớn có thêm lợi ích về governance và traceability, nhưng SDD không bắt buộc phải nặng.

4. “SDD bắt phải dùng DDD và Hexagonal”

Không bắt buộc. DDD và Hexagonal Architecture chỉ rất hợp với SDD. Hoàn toàn có thể bắt đầu nhỏ: đặt tên entity đúng (Ubiquitous Language), tách use case rõ, viết AC có test. Sau một thời gian, team thường tự thấy cần Bounded Context và Port và Adapter.

5. “AI càng giỏi thì càng không cần spec”

Ngược lại. AI càng giỏi viết code, câu hỏi “viết đúng cái gì?” càng quan trọng. Spec là cách team trả lời câu đó một cách bền hơn prompt rời rạc. Đây là câu thần chú trung tâm của cả cuốn sách → AI-Assisted.

Liên quan

Graph View

Backlinks