2.1 · Spec-Driven Development

2.1 · Spec-Driven Development

Mục tiêu: Hiểu và áp dụng được quy trình Spec-Driven Development vào công việc hàng ngày.

Quy trình chuẩn

Requirement → Spec → Task list → Code generation → Review → Ship

Mỗi bước có mục đích rõ ràng và output cụ thể. Không skip bước nào.

Tại sao Spec trước Code?

1 · AI generate code tốt hơn ~40%

2 · Giảm vòng lặp sửa lỗi

Kịch bản thường gặp:

3 · Spec là tài liệu sống

Lợi ích:

• Onboard member mới nhanh hơn
• Dễ maintain sau 6 tháng
• Dễ handover khi đổi người
• Dễ viết test case

So sánh: Code không có Spec vs có Spec

Case Study: Feature “User Profile Edit”

## Feature: User Profile Edit

### Goals
- User có thể cập nhật thông tin cá nhân
- Đảm bảo data integrity

### User Story
As a logged-in user, I want to edit my profile
so that my information is up-to-date.

### Editable Fields
- Full name (required, 2-50 chars)
- Phone number (optional, 10 digits)
- Avatar (optional, max 2MB, crop to square)

### Non-editable Fields
- Email (display only, cannot change)
- Username (display only)

### Validation
- Name: không chứa số hoặc ký tự đặc biệt
- Phone: regex ^\d{10}$
- Avatar: JPEG/PNG only

### Acceptance Criteria
- [ ] Form hiển thị đúng current data
- [ ] Validation realtime khi user nhập
- [ ] Save button disabled khi invalid
- [ ] Success message sau khi save
- [ ] Avatar preview trước khi upload

Chuyển Requirement mơ hồ → Spec rõ ràng

Bước 1: Hỏi đúng câu hỏi

Khi nhận requirement mơ hồ, hỏi:

5W1H Framework:

• What: Feature này làm gì chính xác?
• Who: Ai sẽ dùng? (role, permission)
• When: Khi nào feature này được trigger?
• Where: Ở đâu trong app? (page, section)
• Why: Tại sao cần feature này? (business goal)
• How: Hoạt động như thế nào? (flow, logic)

Bước 2: Liệt kê Edge Cases

Ví dụ: Feature “Add to Cart”

Happy path: User click “Add”, item vào cart.

Edge cases cần clarify:

• Item đã hết hàng?
• User chưa login?
• Cart đã đầy (max 50 items)?
• Item đã có trong cart?
• Quantity > stock available?

Mỗi case cần có behavior rõ ràng trong spec.

Bước 3: Viết Acceptance Criteria

Acceptance Criteria = checklist để verify feature hoạt động đúng.

Format:

- [ ] Given [context], when [action], then [result]

Ví dụ:

- [ ] Given user chưa login, when click "Add to Cart", then redirect to login page
- [ ] Given item hết hàng, when view product, then button "Add to Cart" disabled
- [ ] Given cart đã có item, when add same item, then increase quantity

Task Decomposition

Feature lớn cần chia nhỏ thành tasks để AI xử lý hiệu quả.

Nguyên tắc chia task

1 task = 1 file hoặc 1 component

Workflow thực tế

Áp dụng vào công việc thực tế

Spec-Driven Development phát huy hiệu quả nhất khi áp dụng vào các feature thực tế. Hãy thử với một feature bạn đang làm hoặc sắp làm.

Cấu trúc spec đầy đủ bao gồm:

• Goals & Non-goals rõ ràng
• User stories mô tả nhu cầu người dùng
• Technical design chi tiết (API, data model, components)
• Edge cases để xử lý các tình huống đặc biệt
• Acceptance criteria để verify feature hoạt động đúng
• Task list với estimate để quản lý tiến độ

Đặc điểm của spec chất lượng:

• Đủ rõ để người khác đọc hiểu ngay
• Cover ít nhất 3–5 edge cases quan trọng
• Có 5–10 acceptance criteria cụ thể
• Task list có 4–8 tasks, mỗi task 30–90 phút

Tiếp theo

Bạn đã hiểu quy trình Spec-Driven Development. Bước tiếp theo là học cách dùng đúng công cụ đúng việc — kết hợp Reasoning Model (Claude, ChatGPT) và Coding Agent (Cursor, Kiro, Antigravity) để tối đa hoá hiệu quả.