Refactor code bằng AI là việc sử dụng trợ lý để đề xuất các thay đổi trong cấu trúc mã nguồn như tách hàm hoặc giảm thiểu sự lặp lại mà vẫn giữ nguyên hành vi đã quan sát được. Trước khi tiến hành, cần xác định các invariant, chạy thử nghiệm cơ bản, xem xét từng sự thay đổi nhỏ và kiểm tra lại. AI không tự chứng minh sự thay đổi là an toàn. Các thay đổi nhỏ giúp duy trì phạm vi và kiểm tra hành vi.
Mục lục
- Refactor là gì và không phải gì?
- Chọn phạm vi và dấu hiệu
- Thuộc tính cần giữ
- Quy trình refactor có AI hỗ trợ
- Ví dụ và prompt
- Review và xác minh kết quả
- Lỗi thường gặp
- Checklist an toàn
- Nguồn tham khảo
- Câu hỏi thường gặp
Refactor là gì và không phải gì?
Martin Fowler định nghĩa refactoring là việc tái cấu trúc phần mềm mà không làm thay đổi hành vi đã quan sát được; thường gồm các biến đổi nhỏ, giúp duy trì hành vi qua từng bước. Định nghĩa này giúp phân biệt refactor với sửa lỗi hoặc thêm tính năng. Nếu cần thay đổi cả quy tắc nghiệp vụ và cấu trúc mã, hãy tách chúng thành các thay đổi riêng để biết rõ thử nghiệm nào đang chứng minh điều gì.
AI có khả năng đọc đoạn mã đã được cung cấp, gợi ý tên tốt hơn, tách phần tính toán đơn thuần, giảm lặp hoặc chỉ ra các nhánh khó hiểu. Nó cũng có thể thay đổi logic vì cho rằng cách viết mới “hợp lý” hơn, đổi thứ tự thao tác có side effect hoặc bỏ qua nhánh hiếm. Do đó, mô hình hỗ trợ thao tác nhưng kỹ sư phải xác định hợp đồng và quyết định phạm vi.
Refactor không đồng nghĩa với việc viết lại toàn bộ tập tin, đổi framework hay “làm sạch mã” theo gu cá nhân. Thay đổi càng lớn thì càng khó xác định nguyên nhân nếu thử nghiệm thất bại. Một chuỗi thay đổi hẹp giúp người kiểm tra so sánh trước/sau và quay lại bước gần nhất nếu hành vi sai lệch.
Chọn phạm vi và dấu hiệu
Việc refactor có thể được xem xét khi việc sửa chữa cùng một khu vực lặp lại khó khăn, tên biến che khuất khái niệm, nhiều nhánh trộn các trách nhiệm, hoặc sự trùng lặp khiến một quy tắc phải cập nhật ở nhiều nơi. “Mã không đẹp” chưa đủ lý do nếu thay đổi không đem lại lợi ích và tạo rủi ro ngoài mục tiêu.
Viết câu mục tiêu một dòng, ví dụ: “tách phần tính thuế ra khỏi luồng lưu hóa đơn để kiểm tra quy tắc độc lập, giữ nguyên kết quả và ngoại lệ hiện tại.” Sau đó xác định phạm vi tập tin/hàm và phần nằm ngoài phạm vi. Không để AI tự mở rộng sang module khác chỉ vì phát hiện thêm cơ hội dọn dẹp.
Nếu hệ thống thiếu thử nghiệm và hành vi chưa được mô tả, trước tiên thu thập ví dụ từ log/thử nghiệm thủ công hoặc chủ sở hữu. Thử nghiệm đặc trưng có thể ghi lại hành vi hiện hữu, nhưng cần xác nhận hành vi đó có chủ đích hay là lỗi. Nếu không xác nhận được, đánh dấu rủi ro rõ ràng và tránh gọi thay đổi là refactor thuần túy.
Thuộc tính cần giữ
Trước khi đưa ra yêu cầu, ghi lại hợp đồng có thể quan sát và điều không được thay đổi. Sử dụng các thuộc tính này làm danh sách kiểm tra cho thử nghiệm, xem xét và nội dung bàn giao.
- Input/output: kiểu dữ liệu, giá trị mặc định, định dạng, thứ tự và kết quả biên.
- Lỗi: điều kiện ném ngoại lệ, loại lỗi hoặc trạng thái trả về được gọi hàm xử lý.
- Side effect: ghi cơ sở dữ liệu, gửi sự kiện, gọi API, đọc đồng hồ, thao tác tệp hay thay đổi trạng thái.
- Thứ tự: trình tự side effect/kiểm tra nếu gọi hàm hoặc hệ thống phụ thuộc vào nó.
- API công khai: tên phương thức, schema, hợp đồng, sự kiện và tính tương thích cần duy trì.
- Hiệu năng/tài nguyên: vòng lặp, truy vấn, bộ nhớ hoặc thời gian chờ có liên quan tới yêu cầu.
- Hành vi không đổi: tiêu chí bên ngoài mà thử nghiệm có thể xác nhận sau từng bước.
