Tái cấu trúc Code bằng AI mà không làm hỏng hệ thống

Cập nhật lần cuối: June 27, 2026

Việc tái cấu trúc từng có nghĩa là một buổi chiều yên tĩnh, một bộ kiểm thử màu xanh lá cây và rất nhiều việc đổi tên cẩn thận. AI thay đổi tốc độ của công việc đó, chứ không phải kỷ luật đằng sau nó. Một mô hình có thể đổi tên một ký hiệu qua bốn mươi file chỉ trong vài giây, nhưng nó cũng có thể tự tin xóa bỏ một nhánh đã xử lý trường hợp biên thanh toán cách đây ba năm.

Đây là hướng dẫn thực hành về việc sử dụng AI để tái cấu trúc theo cách mà một kỹ sư cẩn thận sẽ làm: từng bước nhỏ, giữ nguyên hành vi, và các bài kiểm thử bảo vệ mọi động thái.

Câu trả lời nhanh: làm thế nào để tái cấu trúc bằng AI mà không gây lỗi?

Hãy coi AI như một kỹ sư cấp dưới nhanh nhẹn, người không bao giờ mệt và không bao giờ đọc ticket. Bạn vẫn chịu trách nhiệm về hành vi.

Trước hết hãy ghim hành vi bằng các bài kiểm thử, sau đó yêu cầu thay đổi nhỏ từng bước một, rồi xem xét diff trước khi chấp nhận nó. Tái cấu trúc có nghĩa là thay đổi cấu trúc trong khi giữ nguyên hành vi quan sát được, một định nghĩa mà Martin Fowler đã đưa ra trong refactoring catalog của mình. Nếu một thay đổi làm thay đổi hành vi, đó là viết lại (rewrite) hoặc sửa lỗi (bug fix), và nó cần sự xem xét khác biệt.

Một quy trình làm việc vững vàng dưới áp lực thời hạn thực tế:

1. Khóa hành vi hiện tại bằng các bài kiểm thử đặc trưng (characterization tests).
2. Đưa ra một mục tiêu hẹp, có tên ("trích xuất validation này thành một hàm thuần túy").
3. Đọc toàn bộ diff, không chỉ bản tóm tắt.
4. Chạy suite và linter trước khi bạn commit.
5. Commit từng bước xanh lá cây riêng biệt để sau này bạn có thể bisect (tìm ra điểm thay đổi).

Giữ các thay đổi có thể merge được. Một refactor 40 dòng vượt qua đánh giá sẽ tốt hơn một "dọn dẹp" 2,000 dòng mà không người đánh giá nào xác minh được.

AI thực sự có thể làm gì trong quá trình tái cấu trúc?

AI mạnh nhất ở những phần cơ học, nặng về mẫu (pattern-heavy) của việc tái cấu trúc và yếu nhất ở ý định (intent).

Nó làm tốt việc đổi tên qua một module, trích xuất các hàm, chuyển đổi chuỗi callback thành async/await, chia một god class lớn thành nhiều collaborator nhỏ hơn, và dịch một file từ idiom framework này sang idiom khác. Nó gặp khó khăn khi "cấu trúc đúng" phụ thuộc vào các quy tắc nghiệp vụ nằm trong đầu ai đó hoặc trong một bình luận Jira từ năm 2022.

Một thói quen hữu ích: yêu cầu mô hình giải thích mã hiện có trước khi nó thay đổi bất cứ điều gì. Nếu bản tóm tắt của nó sai, refactor của nó cũng sẽ sai, và bạn vừa phát hiện ra miễn phí.

Làm thế nào để giữ các bài kiểm thử xanh lá cây trong khi AI viết lại mã?

Các bài kiểm thử là hợp đồng (contract). Không có chúng, một refactor bằng AI chỉ là một phỏng đoán đầy hy vọng.

Khi đoạn mã bạn muốn chạm vào không có coverage, hãy viết các bài kiểm thử đặc trưng trước. Chúng ghi lại những gì mã đang làm ngày hôm nay, chứ không phải nó nên làm gì, vì vậy bất kỳ thay đổi hành vi nào cũng sẽ xuất hiện dưới dạng một bài kiểm thử đỏ (red test). Kỹ thuật này được mô tả trong Wikipedia entry on characterization tests, và nó là lưới an toàn có giá trị nhất trước khi để mô hình tự do trên mã kế thừa (legacy code).

Sử dụng thứ tự này trên một module chưa được kiểm thử:

1. Chạy các đường dẫn mã và ghi lại đầu vào và đầu ra thực tế.
2. Viết các bài kiểm thử khẳng định những đầu ra chính xác đó, ngay cả những cái xấu xí nhất.
3. Xác nhận suite xanh lá cây và tốc độ hợp lý.
4. Để AI tái cấu trúc từng bước nhỏ.
5. Theo dõi bất kỳ bài kiểm thử nào chuyển sang màu đỏ, và dừng lại ở đó.

Một nhóm tôi từng làm việc có một máy tính hóa đơn 600 dòng mà không ai muốn chạm vào. Chúng tôi dành cả buổi sáng để viết 30 bài kiểm thử đặc trưng chống lại các mẫu sản xuất, sau đó yêu cầu mô hình chia hàm thành các bước được đặt tên. Hai bài kiểm thử chuyển sang màu đỏ về việc làm tròn số (rounding). Màu đỏ đó chính là điểm mấu chốt: mã cũ làm tròn theo từng dòng mục, refactor làm tròn một lần ở cuối. Chúng tôi giữ lại hành vi cũ và triển khai. Để có chiến lược kiểm thử sâu hơn, hãy sử dụng vòng lặp xem xét và xác minh bên dưới.

Quy trình tái cấu trúc AI an toàn, từng bước

Sử dụng cùng một vòng lặp dù bạn đang ở trong trợ lý IDE hay một agent terminal như Claude Code.

1. Phạm vi hóa (Scope it). Đặt tên cho một refactoring với ranh giới rõ ràng: "Trích xuất logic retry từ OrderService vào RetryPolicy," chứ không phải "dọn dẹp các đơn hàng."
2. Ghim hành vi (Pin behavior). Đảm bảo rằng các bài kiểm thử bao phủ các dòng bạn sẽ thay đổi; thêm chúng nếu bị thiếu.
3. Prompt hẹp (Prompt narrowly). Dán mã mục tiêu và một ràng buộc: giữ nguyên giao diện công khai (public interface).
4. Đọc diff. Theo dõi các nhánh bị loại bỏ, giá trị mặc định bị thay đổi, toán tử hoán đổi, và kiểm tra null đã bị xóa.
5. Xác minh (Verify). Chạy các bài kiểm thử, type checker, và linter. Chạy lại integration tests nếu I/O thay đổi.
6. Commit nhỏ (Commit small). Một refactor xanh lá cây mỗi commit; đặt tên cho cấu trúc đã thay đổi.
7. Mở PR để xem xét. Giữ các diff đủ nhỏ để đồng đội có thể đọc được.

Bước xem xét là quan trọng nhất. Các diff do AI tạo ra trông tự tin và sạch sẽ, đó chính xác là lý do chúng dễ bị bỏ qua. Hãy đọc mọi dòng đã thay đổi, và nghi ngờ bất kỳ việc xóa nào mà bạn không yêu cầu.

Làm thế nào để phát hiện code smells bằng AI?

AI giỏi trong việc đặt tên các mùi (smells), sau đó trung bình trong việc khắc phục chúng. Hãy sử dụng nó như một thiết bị phát hiện trước và là một trình chỉnh sửa thứ hai.

Chỉ vào một file và hỏi những hàm nào quá dài, nơi sự trùng lặp ẩn náu, tham số nào đi cùng nhau và nên là một object, và nơi các điều kiện (conditionals) đã lớn thành một bụi rậm. Catalog of code smells của Fowler vẫn là từ vựng chung rõ ràng nhất, và một mô hình biết những thuật ngữ đó sẽ cung cấp cho bạn những phát hiện mà người đánh giá có thể tranh luận được.

Đừng để nó "sửa tất cả mùi" trong một lần. Báo cáo về mùi là một danh sách việc cần làm, chứ không phải mệnh lệnh. Một số sự trùng lặp là ổn. Một số hàm dài là dài vì miền (domain) của nó yêu cầu như vậy.

Công cụ và vị trí của chúng

Công cụ quan trọng hơn vòng lặp xung quanh nó, nhưng loại hình định hình cách bạn làm việc.

• Trợ lý inline IDE gợi ý chỉnh sửa khi bạn gõ và rất tốt cho các refactor nhỏ, cục bộ.
• Trợ lý kiểu chat (Chat-style assistants) tốt cho việc "giải thích rồi tái cấu trúc" trên một file hoặc hàm được dán vào.
• Agent terminal có thể chạy kiểm thử và chỉnh sửa nhiều files, điều này vừa mạnh mẽ vừa rủi ro ngang nhau.
• Static analysis và linters bắt các vấn đề cơ học mà AI đôi khi bịa ra, vì vậy hãy giữ chúng trong vòng lặp.

Dù bạn chọn gì, version control là thiết bị an toàn thực sự của bạn. Commit trước khi bắt đầu, branch cho công việc, và giữ mỗi bước AI như một commit riêng biệt. Khi một agent chỉnh sửa mười hai files và một assertion bị lỗi, lịch sử sạch sẽ cho phép bạn bisect đến chính xác thay đổi đó thay vì đọc lại mọi thứ.

Nếu bạn cũng khắc phục các lỗi được giới thiệu giữa chừng refactor, vòng lặp có phương pháp tương tự này kết hợp tốt với quy trình làm việc này. Có câu hỏi nào về quy trình không? FAQ bao gồm những câu hỏi phổ biến.

Làm thế nào để hiện đại hóa mã kế thừa tăng dần?

Viết lại toàn bộ (Big-bang rewrites) thất bại từ từ. Hiện đại hóa tăng dần chiến thắng vì mọi bước đều được triển khai.

Mẫu strangler là hình dạng đã được chứng minh: xây dựng đường dẫn mới bên cạnh cái cũ, định tuyến một phần các lời gọi qua nó, xác minh, sau đó mở rộng cho đến khi mã cũ chết và bạn xóa nó đi. Martin Fowler đã ghi lại điều này là strangler fig application, và AI giúp công việc theo từng lát cắt nhanh hơn mà không thay đổi chiến lược.

Sử dụng AI bên trong mỗi lát cắt, chứ không phải trên toàn bộ quá trình di chuyển:

1. Chọn một endpoint, màn hình hoặc module để hiện đại hóa.
2. Ghim hành vi của nó bằng các bài kiểm thử chống lại triển khai hiện tại.
3. Yêu cầu mô hình tạo ra phiên bản hiện đại của chỉ lát cắt đó.
4. Chạy cả cũ và mới với cùng đầu vào và diff các đầu ra.
5. Cắt chuyển (Cut over) lát cắt, theo dõi sản xuất, sau đó chuyển sang cái tiếp theo.

Điều này giữ cho bán kính bùng nổ nhỏ. Nếu mô hình hiểu sai một lát cắt, bạn mất một lát cắt, chứ không phải cả hệ thống.

Khi nào bạn không nên để AI tái cấu trúc?

Một số mã nên được thực hiện thủ công cho đến khi bạn hoàn toàn hiểu nó.

Hãy kiềm chế AI khi:

• Mã xử lý tiền bạc, auth, quyền hạn, hoặc bất cứ thứ gì mà compliance quan tâm.
• Không có bài kiểm thử và bạn chưa thể viết các bài kiểm thử đặc trưng.
• Hành vi phụ thuộc vào các quy tắc nghiệp vụ không được ghi lại tài liệu.
• Diff sẽ quá lớn để bất kỳ ai xem xét một cách trung thực.
• Một lỗi tinh tế ở đây sẽ tốn kém hoặc khó phát hiện trong sản xuất.

Trong những trường hợp đó, hãy sử dụng AI để giải thích và lập kế hoạch, sau đó tự mình thực hiện các chỉnh sửa theo từng bước nhỏ, được xem xét. Refactor nhanh nhất là refactor mà bạn không bao giờ phải hoàn tác. Ghim hành vi, thay đổi một thứ, giữ suite xanh lá cây, và để AI xử lý việc gõ phím trong khi bạn giữ sự phán đoán.

Để quy trình agentic rộng hơn xung quanh vòng lặp này, hãy xem hướng dẫn AI agent automation và ghi chú AI API development. Bài viết MCP model context bao gồm cách một agent tiếp cận các công cụ bên ngoài mà đôi khi việc refactor cần.

Credit hình ảnh

Các hình ảnh bài viết được lấy từ Pexels và lưu trữ trên CDN dự án để hiển thị trang ổn định.