Tái cấu trúc mã nguồn theo kế hoạch

Tags: Refactoring | Planning | Risk control | Code quality

1. Mục đích

Sử dụng chế độ Lập kế hoạch (Plan mode) khi việc tái cấu trúc (refactoring) ảnh hưởng đến nhiều file, làm thay đổi kiến trúc hoặc đòi hỏi phải bảo toàn nghiêm ngặt hành vi hiện tại của hệ thống. CodeVista sẽ phân tích vùng mã nguồn mục tiêu và lập ra một kế hoạch có thể xem xét, đánh giá trước mà không hề chỉnh sửa bất kỳ file nào trong giai đoạn lập kế hoạch.

2. Trước khi bắt đầu

• Mở repository và chọn chế độ Plan trên giao diện CodeVista.
• Xác định rõ mục tiêu cần tối ưu, kết quả mong muốn, các phần loại trừ và các yêu cầu tương thích bắt buộc.
• Xác định các bài kiểm thử hoặc các bước kiểm chứng để bảo toàn hành vi hiện tại.

3. Lời nhắc khởi động (Starter Prompt)

Hãy lập kế hoạch tái cấu trúc [file, module hoặc vùng code mục tiêu] nhằm [mục tiêu]. 
 
Ràng buộc: 
- [Ràng buộc hoặc hướng dẫn triển khai tạm thời] 
- Bảo toàn [interface, hành vi hiện tại hoặc yêu cầu tương thích] 
- Không thay đổi [các file hoặc hành vi được loại trừ] 
 
Trong quá trình lập kế hoạch: 
1. Phân tích mã nguồn và các dependency liên quan. 
2. Xác định các vấn đề hiện tại, các file bị ảnh hưởng và rủi ro triển khai. 
3. Tạo một kế hoạch tái cấu trúc có đánh số thứ tự từng bước. 
4. Giải thích thay đổi dự kiến và phương thức kiểm chứng cho mỗi bước. 
5. Không chỉnh sửa bất kỳ file nào. 
 
Kết thúc bằng dòng Trạng thái: Chờ phê duyệt (Status: Waiting for approval).

Ví dụ thực tế

Lập kế hoạch tái cấu trúc giá trị context token bị hardcode trong file src/prototyper-cline/src/codevista/adapter.ts thành một lời gọi Backend API. Tạm thời stub phản hồi từ backend. Không chỉnh sửa bất kỳ file nào cho đến khi tôi phê duyệt kế hoạch.

4. Cách sử dụng

1. Mở repository và chuyển sang chế độ Plan mode.
2. Gửi mục tiêu tái cấu trúc, phạm vi mục tiêu và các ràng buộc.
3. Xem xét danh sách các file được đề xuất, dependencies, rủi ro và các bước kiểm chứng.
4. Yêu cầu CodeVista điều chỉnh kế hoạch nếu phạm vi quá rộng hoặc chưa đầy đủ.
5. Phê duyệt kế hoạch và chỉ cho phép triển khai khi kế hoạch đã sẵn sàng.
6. Chạy các bước kiểm chứng đã lên kế hoạch và xem xét diff cuối cùng.

5. Kết quả mong đợi

• Phạm vi có thể xem xét: Các file bị ảnh hưởng, các phụ thuộc và thay đổi dự kiến đều hiển thị rõ ràng trước khi code.
• Kiểm soát rủi ro: Bạn có thể thu hẹp, từ chối hoặc yêu cầu sửa đổi kế hoạch trước khi có bất kỳ file nào bị can thiệp.
• Thực thi đồng bộ: Các thay đổi đã duyệt có thể được áp dụng tuần tự, chặt chẽ trên nhiều file.
• Bảo toàn hành vi: Kế hoạch bao gồm các bài kiểm tra tập trung hoặc các bước kiểm tra để đảm bảo logic hiện tại không bị lỗi.

6. Mẹo hữu ích

• Giữ bản kế hoạch đầu tiên tập trung vào một hành vi hoặc một mối quan tâm kiến trúc cụ thể.
• Nêu rõ các public interface và hành vi nghiệp vụ bắt buộc phải giữ nguyên trạng.
• Luôn yêu cầu một bước kiểm chứng tương ứng cho mỗi thay đổi nhạy cảm về mặt hành vi.