Giao diện
Sửa lỗi với Spec Kit
Trước khi bắt đầu
- Cần biết: Spec Kit là gì và quy trình SDD (Spec-Driven Development) hoạt động ra sao; nếu chưa biết, đọc trước trang Spec Kit là gì?
- Cần có: Spec Kit đã cài trên máy, một dự án đã chạy
specify init, và một lỗi có thể mô tả lại bằng lời - Cần đang ở: thư mục gốc của dự án đang chứa lỗi cần sửa
1. Nhóm này dành cho ai
Nhóm trang này dành cho người đã có mã nguồn đang chạy và phát hiện một hành vi sai. Bạn không cần viết tính năng mới, không cần bản đặc tả (specification) đầy đủ. Bạn cần một chẩn đoán có căn cứ, một bản sửa gọn, và bằng chứng cho thấy lỗi đã hết.
Đây là nhóm trang dành cho tình huống "cái này đang chạy sai". Nếu việc bạn muốn làm là thêm một khả năng chưa từng có, hãy dùng nhóm Xây dựng thay vì nhóm này.
2. Khi nào dùng nhóm này, khi nào không
Dùng nhóm Sửa lỗi khi bạn trả lời "có" cho ít nhất một câu sau:
- Hành vi hiện tại khác với hành vi được mong đợi.
- Có bước tái hiện (reproduction) mà người khác làm lại được.
- Có thông báo lỗi, ảnh chụp, hoặc liên kết tới issue mô tả vấn đề.
Không dùng nhóm này khi:
- Bạn muốn thêm tính năng mới → dùng nhóm Xây dựng.
- Bạn chỉ có một ý tưởng và chưa biết có đáng đầu tư không → dùng nhóm Đánh giá.
- Bạn chưa chứng minh được đây là lỗi → hãy ghi lại bằng chứng trước, vì quy trình này chỉ nhận một lỗi có thật.
3. Đọc theo thứ tự nào
Nhóm này có hai trang. Đọc theo đúng thứ tự sau:
- Quy trình sửa lỗi — đọc trước để nắm ba bước
assess→fix→test, biết tiện ích mở rộng (extension)bugcài thế nào, và hiểu vì sao quy trình này tách khỏi quy trình SDD chính. - Chi tiết từng bước — đọc sau khi đã cài tiện ích; trang này mô tả từng bước một, lệnh cụ thể, và tệp nào được tạo ra ở mỗi bước.
Hai trang có mục đích khác nhau: trang đầu trả lời "quy trình này gồm những gì và vì sao", trang sau trả lời "gõ gì, theo thứ tự nào, xem tệp ở đâu". Bạn có thể quay lại trang đầu khi cần giải thích quy trình cho người khác trong nhóm.
4. Bạn sẽ gặp những thuật ngữ nào
- Lỗi (bug): một hành vi sai có thể tái hiện, khác với hành vi được mong đợi.
slug: tên ngắn, không dấu, dùng lại ở cả ba bước để Spec Kit biết các tệp thuộc cùng một lỗi. Ví dụlogin-crash.- Đánh giá (assessment): bước tìm nguyên nhân gốc, chỉ ghi chép, không sửa mã nguồn.
- Bản sửa (fix): bước duy nhất được phép sửa mã nguồn.
- Kiểm chứng (test): bước chạy lại cách tái hiện và các bài kiểm thử liên quan, rồi ghi lại bằng chứng.
- Phán quyết (verdict): kết luận của bước kiểm chứng, gồm
verified,partial, hoặcfailed.
5. Nhóm này liên hệ thế nào với các nhóm khác
Ba nhóm nghiệp vụ trên website trả lời ba câu hỏi khác nhau, và bạn chỉ cần đúng một nhóm cho mỗi tình huống:
| Câu hỏi của bạn | Nhóm cần dùng |
|---|---|
| Thêm một khả năng chưa từng có | Xây dựng |
| Một hành vi đang chạy sai | Sửa lỗi (trang này) |
| Ý tưởng này có đáng đầu tư không | Đánh giá |
Hai nhóm Sửa lỗi và Đánh giá đều không thay thế nhóm Xây dựng. Chúng xử lý hai tình huống mà quy trình SDD đầy đủ là quá nặng: sửa một hành vi sai đã biết, và quyết định trước khi cam kết đầu tư.
6. Bạn sẽ tạo ra những gì
Sau khi chạy hết quy trình, bạn có một thư mục .specify/bugs/<slug>/ chứa ba tệp: chẩn đoán, bản ghi thay đổi, và bằng chứng kiểm chứng. Đây là hồ sơ để người duyệt đi từ triệu chứng tới bằng chứng mà không phải hỏi thêm.
Bạn không tạo bản đặc tả, không tạo kế hoạch, và không tạo danh sách công việc. Đó là chủ ý, không phải thiếu sót.
Kết quả
Sau khi hoàn thành trang này, bạn đã:
- Biết nhóm Sửa lỗi phục vụ ai và khi nào nên dùng nó
- Biết thứ tự đọc hai trang còn lại và mỗi trang giúp bạn việc gì
- Nắm được sáu thuật ngữ sẽ gặp xuyên suốt nhóm
Cách tự xác nhận: bạn kể lại được bằng lời ba bước assess → fix → test và nói rõ bước nào được phép sửa mã nguồn.
Nguồn tham chiếu: Bug Fixing QuickstartPhiên bản kiểm chứng: Spec Kit 1.1.3