Cách dùng Vibe Coding để refactor mã nguồn

Refactor mã nguồn là công việc quan trọng trong quá trình phát triển phần mềm, giúp cải thiện cấu trúc code, giảm sự trùng lặp và tăng khả năng bảo trì mà không làm thay đổi hành vi của chương trình. Tuy nhiên, khi dự án có nhiều file, logic phức tạp hoặc tồn tại những đoạn code được viết từ lâu, việc xác định cần sửa ở đâu và sửa như thế nào thường tốn nhiều thời gian.

Vibe Coding có thể hỗ trợ quá trình này bằng cách sử dụng ngôn ngữ tự nhiên để yêu cầu AI đọc hiểu mã nguồn, phát hiện vấn đề, đề xuất phương án cải thiện và thực hiện các thay đổi theo từng bước. Thay vì tự viết lại toàn bộ code, lập trình viên có thể phối hợp với AI để xử lý những phần cần thiết, đồng thời kiểm soát kết quả thông qua việc xem xét thay đổi và chạy kiểm thử.

Tuy nhiên, refactor bằng AI không đơn giản là yêu cầu công cụ làm cho code đẹp hơn. Nếu không xác định rõ phạm vi, ràng buộc và cách kiểm chứng, AI có thể vô tình thay đổi nghiệp vụ, làm hỏng các chức năng đang hoạt động hoặc tạo ra cấu trúc phức tạp hơn ban đầu.

Trong bài viết này, Web Mới sẽ hướng dẫn cách dùng Vibe Coding để refactor mã nguồn theo quy trình thực tế, từ phân tích code hiện có, lựa chọn phần cần cải thiện đến triển khai thay đổi và kiểm tra chất lượng sau khi refactor.

Cách dùng Vibe Coding để refactor mã nguồn
Cách dùng Vibe Coding để refactor mã nguồn

Vibe Coding hỗ trợ refactor mã nguồn như thế nào?

Vibe Coding là cách phát triển phần mềm trong đó lập trình viên mô tả mục tiêu bằng ngôn ngữ tự nhiên, sau đó sử dụng AI để hỗ trợ tạo, chỉnh sửa hoặc giải thích mã nguồn. Với công việc refactor, cách tiếp cận này giúp chuyển những yêu cầu như giảm code trùng lặp, tách hàm dài hoặc làm rõ luồng xử lý thành các thay đổi cụ thể trong dự án.

Điểm quan trọng là AI không chỉ được sử dụng để viết code mới. Khi có đủ ngữ cảnh, công cụ còn có thể phân tích cấu trúc hiện tại, nhận diện các đoạn xử lý tương tự, giải thích mối liên hệ giữa các hàm và đề xuất cách tổ chức lại mã nguồn.

Phát hiện những vấn đề khó nhận ra khi đọc code thủ công

Trong một dự án đã phát triển qua nhiều giai đoạn, code thường tích lũy những vấn đề như hàm quá dài, điều kiện lồng nhau nhiều cấp, logic nghiệp vụ bị lặp lại hoặc một hàm phải đảm nhiệm quá nhiều nhiệm vụ. Những vấn đề này không phải lúc nào cũng gây lỗi ngay lập tức nhưng khiến việc sửa đổi và mở rộng phần mềm ngày càng khó khăn.

AI có thể hỗ trợ đọc các đoạn code liên quan và chỉ ra những điểm đáng xem xét. Chẳng hạn, nếu nhiều hàm cùng thực hiện thao tác kiểm tra dữ liệu đầu vào, công cụ có thể đề xuất một hàm dùng chung. Nếu một phương thức vừa truy vấn cơ sở dữ liệu, vừa xử lý nghiệp vụ và định dạng kết quả trả về, AI có thể đề xuất tách các trách nhiệm này thành những phần riêng biệt.

Dù vậy, các đề xuất chỉ nên được xem là giả thuyết cần xác minh. Một đoạn code trông giống nhau chưa chắc có cùng ý nghĩa nghiệp vụ, còn một hàm dài chưa chắc cần tách nếu việc tách làm luồng xử lý khó hiểu hơn.

Cải thiện cấu trúc mà không viết lại toàn bộ chức năng

Mục tiêu của refactor là cải thiện thiết kế bên trong của mã nguồn trong khi vẫn giữ nguyên hành vi bên ngoài. Đây là điểm cần phân biệt rõ giữa refactor và phát triển tính năng mới.

Ví dụ, một hàm tính tổng đơn hàng có thể đang thực hiện đồng thời việc lấy dữ liệu sản phẩm, kiểm tra số lượng, tính giảm giá và định dạng kết quả. Khi refactor, lập trình viên có thể yêu cầu AI tách những nhiệm vụ này thành các hàm nhỏ hơn, nhưng kết quả tính toán, quy tắc làm tròn và điều kiện áp dụng giảm giá phải được giữ nguyên.

Vibe Coding hữu ích khi thực hiện những thay đổi có phạm vi rõ ràng như:

  • Tách một hàm dài thành các hàm nhỏ theo từng trách nhiệm.
  • Đưa những đoạn xử lý thực sự dùng chung vào một vị trí.
  • Đổi tên biến, hàm hoặc lớp để thể hiện đúng mục đích sử dụng.
  • Giảm các nhánh điều kiện lồng nhau nhưng vẫn bảo toàn logic.
  • Tách phần xử lý nghiệp vụ khỏi phần truy cập dữ liệu hoặc giao diện.
  • Loại bỏ code thừa sau khi xác minh không còn nơi nào sử dụng.

Không nên yêu cầu AI đồng thời thay đổi kiến trúc, viết lại nghiệp vụ, nâng cấp thư viện và tối ưu hiệu năng trong một lần. Khi quá nhiều yếu tố thay đổi cùng lúc, việc xác định nguyên nhân nếu xuất hiện lỗi sẽ khó khăn hơn đáng kể.

Rút ngắn thời gian tìm hiểu mã nguồn cũ

Với những dự án được bàn giao từ lập trình viên khác hoặc đã phát triển trong nhiều năm, hiểu được lý do một đoạn code được viết theo cách hiện tại có thể khó hơn việc sửa chính đoạn code đó. Các quy tắc nghiệp vụ đôi khi nằm rải rác trong nhiều file, còn tên hàm và cách tổ chức thư mục không phản ánh đầy đủ chức năng thực tế.

Trong trường hợp này, có thể sử dụng AI để giải thích luồng xử lý, xác định các hàm liên quan và lập bản đồ những thành phần có khả năng bị ảnh hưởng khi thay đổi. Việc này đặc biệt hữu ích trước khi refactor một module quan trọng.

Tuy nhiên, AI chỉ có thể phân tích dựa trên thông tin mà công cụ được cung cấp hoặc có thể truy cập. Nếu chưa đọc đủ các file liên quan, chưa biết cấu trúc cơ sở dữ liệu hoặc chưa hiểu những tích hợp bên ngoài, công cụ có thể đưa ra nhận định thiếu chính xác. Vì vậy, bước tìm hiểu phải diễn ra trước khi cho phép thực hiện thay đổi.

Những nguyên tắc cần xác định trước khi bắt đầu

Trước khi sử dụng Vibe Coding để chỉnh sửa một dự án đang hoạt động, cần thống nhất mục tiêu, phạm vi và tiêu chí đánh giá kết quả. Đây là cơ sở để AI không tự ý mở rộng công việc sang những phần không cần thiết.

Giữ nguyên hành vi của chương trình

Nguyên tắc quan trọng nhất là không làm thay đổi kết quả nghiệp vụ nếu yêu cầu chỉ liên quan đến refactor. Một đoạn code có thể chưa đẹp nhưng đang xử lý những trường hợp đặc biệt mà tài liệu không đề cập. Nếu AI loại bỏ các trường hợp này vì cho rằng chúng không cần thiết, chương trình có thể phát sinh lỗi dù cấu trúc code mới trông hợp lý hơn.

Trước khi thay đổi, cần xác định các hành vi phải được bảo toàn, bao gồm:

  • Giá trị đầu vào và đầu ra của các hàm quan trọng.
  • Quy tắc nghiệp vụ, điều kiện kiểm tra và thứ tự xử lý.
  • Cấu trúc dữ liệu trả về, mã trạng thái và thông báo lỗi nếu chúng thuộc giao diện được các thành phần khác sử dụng.
  • Hành vi khi dữ liệu rỗng, không hợp lệ hoặc thiếu một số trường.
  • Các tác động phụ như ghi dữ liệu, gửi thông báo, cập nhật trạng thái hoặc gọi API bên ngoài.

Không phải mọi chi tiết triển khai đều cần giữ nguyên. Những thành phần nội bộ có thể được tổ chức lại khi cần thiết, miễn là các hành vi được cam kết với phần còn lại của hệ thống không bị thay đổi ngoài phạm vi yêu cầu.

Chỉ refactor trong phạm vi có thể kiểm soát

Phạm vi thay đổi càng lớn thì nguy cơ phát sinh lỗi và độ khó khi kiểm tra càng cao. Vì vậy, nên bắt đầu từ một hàm, một lớp hoặc một module có ranh giới tương đối rõ ràng thay vì yêu cầu AI làm sạch toàn bộ dự án ngay lập tức.

Chẳng hạn, nếu muốn cải thiện module quản lý khách hàng, hãy bắt đầu với phần chuẩn hóa dữ liệu hoặc một hàm kiểm tra thông tin khách hàng. Sau khi xác nhận kết quả, mới tiếp tục xử lý các thành phần phụ thuộc.

Cách làm này giúp lập trình viên biết chính xác thay đổi nào vừa được thực hiện, dễ so sánh kết quả trước và sau, đồng thời có thể hoàn tác mà không ảnh hưởng đến những phần khác.

Không đồng nhất code ngắn hơn với code tốt hơn

AI có thể đề xuất rút gọn nhiều dòng lệnh thành một biểu thức, sử dụng kỹ thuật lập trình nâng cao hoặc xây dựng thêm lớp trừu tượng. Tuy nhiên, code ít dòng hơn chưa chắc dễ đọc, dễ bảo trì hoặc phù hợp với kiến trúc của dự án.

Một phương án refactor tốt cần được đánh giá dựa trên mức độ rõ ràng, khả năng kiểm thử, sự phù hợp với quy ước hiện có và chi phí bảo trì về sau. Nếu việc thay đổi khiến người phát triển khó hiểu luồng xử lý hơn, thì dù số dòng code giảm xuống, kết quả vẫn có thể là một bước lùi.

Quy trình dùng Vibe Coding để refactor mã nguồn

Để hạn chế việc AI sửa code theo suy đoán, nên chia quá trình refactor thành những bước có đầu vào, đầu ra và tiêu chí kiểm tra cụ thể. Quy trình dưới đây có thể áp dụng cho dự án PHP, JavaScript, Python và nhiều ngôn ngữ lập trình khác.

Bước 1: Kiểm tra trạng thái hiện tại của dự án

Trước tiên, hãy xác định dự án đang ở trạng thái nào trước khi bắt đầu chỉnh sửa. Nếu sử dụng Git, nên kiểm tra các thay đổi chưa được commit và tạo một nhánh riêng cho công việc refactor. Không nên ghi đè lên những thay đổi đang thực hiện dở của bản thân hoặc thành viên khác.

Tiếp theo, xác định các thông tin cơ bản:

  • Ngôn ngữ lập trình, framework và phiên bản đang sử dụng.
  • Cấu trúc thư mục và vị trí của module cần refactor.
  • Cách chạy ứng dụng, kiểm thử và các công cụ kiểm tra chất lượng code.
  • Các thành phần phụ thuộc vào module cần thay đổi.
  • Những lỗi đã tồn tại trước khi bắt đầu công việc.

Đặc biệt, cần chạy các bài kiểm thử hiện có trước khi sửa code. Nếu kiểm thử đã thất bại từ đầu, hãy ghi nhận tình trạng đó để tránh nhầm lẫn lỗi cũ với lỗi do quá trình refactor gây ra.

Với dự án chưa có kiểm thử tự động, nên xác định một số trường hợp đầu vào và đầu ra tiêu biểu để làm căn cứ so sánh. Đối với chức năng quan trọng, có thể viết thêm kiểm thử đặc trưng cho hành vi hiện tại trước khi thay đổi cấu trúc.

Bước 2: Yêu cầu AI phân tích trước, chưa chỉnh sửa code

Sau khi chuẩn bị dự án, hãy yêu cầu công cụ Vibe Coding đọc những file liên quan và báo cáo vấn đề trước khi thực hiện bất kỳ thay đổi nào. Ở bước này, mục tiêu là hiểu rõ code hiện tại chứ không phải tạo ra phiên bản mới ngay lập tức.

Yêu cầu phân tích nên làm rõ bốn vấn đề: đoạn code đang thực hiện nhiệm vụ gì, những thành phần nào phụ thuộc vào nó, vấn đề cấu trúc nằm ở đâu và những rủi ro nào có thể xuất hiện nếu thay đổi.

Ví dụ, với một hàm xử lý đơn hàng, AI cần phân biệt phần kiểm tra dữ liệu đầu vào, phần tính toán giá trị, phần truy vấn cơ sở dữ liệu và phần trả kết quả. Nếu các nhiệm vụ này đang trộn lẫn, công cụ có thể đề xuất cách tách chúng mà không cần thay đổi quy tắc tính tiền.

Không nên chấp nhận một đề xuất chỉ vì AI giải thích nghe hợp lý. Hãy yêu cầu công cụ chỉ rõ vị trí code liên quan và căn cứ cho từng nhận định. Nếu chưa đủ thông tin để kết luận, AI cần nêu rõ những file hoặc dữ liệu còn thiếu thay vì tự suy đoán.

Bước 3: Chọn vấn đề có giá trị cải thiện cao nhất

Sau khi có báo cáo phân tích, hãy lựa chọn một vấn đề cụ thể để xử lý trước. Không phải mọi điểm chưa hoàn hảo đều cần được refactor ngay, nhất là khi phần code đó ít được sử dụng hoặc việc thay đổi có thể ảnh hưởng đến nhiều chức năng quan trọng.

Có thể ưu tiên theo các tiêu chí sau:

Tiêu chí Ý nghĩa Mức độ ưu tiên
Rủi ro bảo trì Code khó hiểu, dễ phát sinh lỗi khi chỉnh sửa hoặc thường xuyên phải thay đổi. Cao
Mức độ lặp lại Nhiều nơi có cùng một logic và việc cập nhật đồng thời đang gây khó khăn. Cao nếu logic thực sự giống nhau
Phạm vi ảnh hưởng Số lượng thành phần có thể bị tác động khi thực hiện thay đổi. Ưu tiên phạm vi nhỏ, dễ kiểm soát
Khả năng kiểm thử Có thể xác minh hành vi trước và sau khi thay đổi hay không. Ưu tiên khi có tiêu chí kiểm tra rõ ràng
Lợi ích thực tế Việc cải thiện có giúp code dễ hiểu, dễ sửa hoặc dễ mở rộng hơn không. Tránh refactor chỉ để thay đổi hình thức

Ví dụ, một hàm tính giá sản phẩm được sử dụng ở nhiều nơi và thường xuyên phát sinh lỗi có thể đáng ưu tiên hơn một hàm dài nhưng ổn định, ít thay đổi và không gây khó khăn trong bảo trì.

Việc chọn đúng vấn đề giúp Vibe Coding phát huy hiệu quả mà không biến công việc cải thiện code thành một đợt viết lại hệ thống ngoài dự kiến.

Bước 4: Yêu cầu AI đề xuất phương án trước khi triển khai

Khi đã xác định phạm vi, hãy yêu cầu AI đưa ra kế hoạch refactor cụ thể. Kế hoạch nên nêu những file cần thay đổi, chức năng của từng phần sau khi tổ chức lại, các điểm có nguy cơ ảnh hưởng và cách kiểm tra kết quả.

Nếu có nhiều phương án, hãy yêu cầu công cụ so sánh dựa trên độ phức tạp, khả năng bảo trì, mức độ tương thích với kiến trúc hiện tại và chi phí triển khai. Không nhất thiết chọn phương án có cấu trúc trừu tượng nhất; trong nhiều dự án, một thay đổi nhỏ và trực tiếp sẽ an toàn hơn.

Trước khi đồng ý, cần kiểm tra xem kế hoạch có vô tình bao gồm những công việc ngoài phạm vi hay không, chẳng hạn đổi tên API công khai, thay đổi cấu trúc cơ sở dữ liệu, nâng cấp thư viện hoặc sửa giao diện không liên quan.

Chỉ khi kế hoạch rõ ràng và có thể kiểm soát, mới chuyển sang bước chỉnh sửa mã nguồn.

Bước 5: Thực hiện thay đổi theo từng phần nhỏ

Không nên yêu cầu AI refactor toàn bộ module trong một lần nếu module đó có nhiều trách nhiệm hoặc phụ thuộc phức tạp. Hãy chia công việc thành những thay đổi nhỏ, mỗi lần tập trung vào một mục tiêu và kiểm tra kết quả trước khi tiếp tục.

Ví dụ, với một module xử lý đơn hàng, có thể thực hiện theo thứ tự:

  1. Tách phần kiểm tra dữ liệu đầu vào khỏi hàm xử lý chính.
  2. Kiểm tra lại hành vi của hàm sau khi tách.
  3. Tách phần tính toán tổng tiền nếu logic đã được xác định rõ.
  4. Chạy kiểm thử cho các trường hợp giảm giá, thuế và làm tròn.
  5. Tiếp tục cải thiện cấu trúc nếu vẫn còn vấn đề đáng xử lý.

Thứ tự này giúp phát hiện lỗi gần với thời điểm phát sinh, giảm số lượng thay đổi phải xem xét và tránh việc nhiều vấn đề chồng chéo khiến quá trình sửa lỗi trở nên khó khăn.

Nếu AI đề xuất chỉnh sửa thêm những file không nằm trong phạm vi đã thống nhất, hãy yêu cầu giải thích lý do trước khi chấp nhận. Chỉ mở rộng phạm vi khi có căn cứ rõ ràng và vẫn kiểm soát được các tác động liên quan.

Bước 6: Xem lại thay đổi và kiểm thử sau mỗi lần refactor

Sau khi AI chỉnh sửa code, không nên chỉ nhìn vào kết quả hiển thị trong trình soạn thảo rồi kết luận công việc đã hoàn thành. Hãy xem lại phần khác biệt giữa phiên bản cũ và mới, xác định những thay đổi thực sự cần thiết và kiểm tra xem có nội dung nào vượt quá yêu cầu hay không.

Nếu dự án sử dụng Git, có thể dùng lệnh sau để xem các thay đổi chưa được đưa vào commit:

git diff

Để kiểm tra trạng thái các file đang thay đổi, sử dụng:

git status

Tiếp theo, chạy bộ kiểm thử liên quan đến phần code vừa chỉnh sửa, sau đó chạy các bài kiểm thử rộng hơn nếu cần. Tùy dự án, có thể bổ sung kiểm tra kiểu dữ liệu, phân tích tĩnh, kiểm tra coding convention hoặc thử nghiệm thủ công các luồng nghiệp vụ quan trọng.

Nếu kiểm thử thất bại, hãy xác định lỗi xuất phát từ thay đổi mới, môi trường chạy hay vấn đề đã tồn tại trước đó. Không nên yêu cầu AI sửa liên tục mà không cung cấp thông tin về lỗi, bởi cách làm này có thể tạo ra nhiều thay đổi mới nhưng không giải quyết đúng nguyên nhân.

Chỉ tiếp tục sang phần tiếp theo khi thay đổi hiện tại đã được xem xét và đạt tiêu chí kiểm tra đã đặt ra. Nếu không thể xác minh rằng hành vi cũ được bảo toàn, cần tạm dừng thay vì mặc định rằng code mới đúng.

Cách viết prompt để AI refactor mã nguồn chính xác

Chất lượng kết quả khi dùng Vibe Coding phụ thuộc rất nhiều vào cách mô tả yêu cầu. Nếu chỉ yêu cầu AI làm sạch code hoặc tối ưu đoạn code này, công cụ có thể tự lựa chọn cách triển khai, mở rộng phạm vi chỉnh sửa hoặc thay đổi những chi tiết mà lập trình viên muốn giữ nguyên.

Một prompt refactor hiệu quả cần xác định rõ mục tiêu, phạm vi, các hành vi phải bảo toàn, giới hạn thay đổi và tiêu chí nghiệm thu. Thay vì yêu cầu AI tạo ra code tốt hơn theo nghĩa chung chung, hãy mô tả cụ thể thế nào là tốt hơn đối với đoạn code đang xử lý.

Xác định rõ mục tiêu và giới hạn chỉnh sửa

Trước khi viết prompt, hãy xác định vấn đề cần giải quyết. Chẳng hạn, nếu một hàm có quá nhiều trách nhiệm, mục tiêu có thể là tách các nhiệm vụ thành những hàm nhỏ hơn. Nếu nhiều đoạn code lặp lại, mục tiêu có thể là đưa logic dùng chung vào một hàm riêng sau khi xác minh rằng chúng có cùng ý nghĩa nghiệp vụ.

Prompt cũng cần nêu những việc AI không được tự ý thực hiện. Đây là phần quan trọng vì nhiều lỗi refactor không xuất phát từ việc AI không biết viết code, mà do công cụ hiểu yêu cầu quá rộng.

Có thể sử dụng mẫu sau để bắt đầu:

Hãy refactor đoạn mã nguồn trong phạm vi tôi chỉ định.

Mục tiêu:
- Cải thiện cấu trúc và khả năng đọc hiểu của code.
- Giảm sự phức tạp không cần thiết.
- Giữ nguyên hành vi nghiệp vụ hiện tại.

Giới hạn:
- Không tự ý thay đổi yêu cầu nghiệp vụ.
- Không thay đổi cấu trúc dữ liệu đầu vào và đầu ra đang được sử dụng.
- Không sửa các file ngoài phạm vi nếu chưa giải thích lý do.
- Không thêm thư viện hoặc thay đổi kiến trúc nếu chưa được chấp thuận.
- Không xóa code chỉ vì cho rằng code đó không cần thiết khi chưa xác minh.

Trước khi chỉnh sửa:
1. Phân tích code hiện tại.
2. Chỉ ra những vấn đề cần refactor.
3. Đề xuất phương án và các rủi ro có thể xảy ra.
4. Chờ xác nhận trước khi thực hiện thay đổi.

Sau khi chỉnh sửa:
1. Giải thích những thay đổi đã thực hiện.
2. Nêu các hành vi cần kiểm tra.
3. Chạy những bài kiểm thử có thể thực hiện.
4. Báo cáo rõ các kiểm thử thành công, thất bại
   và những nội dung chưa thể xác minh.

Mẫu này phù hợp khi bắt đầu với một module chưa quen thuộc hoặc khi thay đổi có khả năng ảnh hưởng đến nhiều thành phần. Với những chỉnh sửa nhỏ, có thể rút gọn prompt nhưng vẫn cần giữ rõ mục tiêu và các giới hạn quan trọng.

Yêu cầu AI refactor dựa trên code thực tế thay vì tự suy đoán

AI có thể đưa ra một phương án hợp lý về mặt lý thuyết nhưng không phù hợp với quy ước hoặc kiến trúc của dự án. Vì vậy, prompt nên yêu cầu công cụ đọc các file liên quan trước khi đưa ra quyết định.

Ví dụ, khi cần refactor một hàm xử lý khách hàng, không nên chỉ cung cấp nội dung của hàm đó nếu kết quả còn phụ thuộc vào các phương thức khác, quy tắc xác thực hoặc cấu trúc dữ liệu được định nghĩa ở nơi khác.

Hãy yêu cầu AI xác định các thành phần sau:

  • Nơi khai báo và những vị trí đang gọi hàm cần thay đổi.
  • Các hàm, lớp hoặc module có liên quan trực tiếp.
  • Các phụ thuộc bên ngoài như cơ sở dữ liệu, API hoặc thư viện.
  • Những quy ước đặt tên, xử lý lỗi và tổ chức code đang được dự án sử dụng.
  • Thông tin còn thiếu khiến phương án refactor chưa thể được xác nhận.

Nếu công cụ không thể truy cập toàn bộ dự án, hãy cung cấp thêm các file cần thiết hoặc yêu cầu AI liệt kê chính xác những thông tin còn thiếu. Không nên để công cụ tự tạo ra các phương thức, thuộc tính hoặc quy tắc nghiệp vụ chưa được xác nhận rồi sử dụng chúng trong phiên bản mới.

Chia yêu cầu lớn thành các prompt có mục tiêu riêng

Một prompt yêu cầu AI vừa phân tích kiến trúc, vừa sửa code, vừa tối ưu hiệu năng, vừa bổ sung kiểm thử thường khó kiểm soát hơn nhiều prompt có phạm vi nhỏ. Khi một lần chỉnh sửa tạo ra nhiều thay đổi, lập trình viên cũng khó xác định thay đổi nào thực sự mang lại lợi ích.

Đối với một module phức tạp, có thể chia công việc thành các yêu cầu nối tiếp nhau:

  1. Phân tích cấu trúc hiện tại và liệt kê những vấn đề cần xử lý.
  2. Đề xuất phương án refactor nhưng chưa chỉnh sửa code.
  3. Thực hiện một thay đổi đã được chấp thuận.
  4. Kiểm tra sự khác biệt và chạy các bài kiểm thử liên quan.
  5. Đánh giá xem có nên tiếp tục cải thiện những phần còn lại hay không.

Cách chia nhỏ này giúp mỗi bước đều có kết quả cụ thể để đánh giá. Nếu phát sinh lỗi, phạm vi cần điều tra cũng hẹp hơn, nhờ đó giảm thời gian khắc phục.

Ví dụ thực tế: Refactor hàm PHP có nhiều trách nhiệm

Để hiểu rõ cách áp dụng Vibe Coding, hãy xem xét một ví dụ PHP đơn giản. Giả sử dự án có một hàm tính tổng đơn hàng, trong đó việc duyệt sản phẩm, tính tiền và kiểm tra dữ liệu đang được đặt chung trong một đoạn code.

Đoạn code dưới đây chỉ nhằm minh họa vấn đề cấu trúc. Trong dự án thực tế, quy tắc tính tiền, giảm giá, thuế và xử lý dữ liệu không hợp lệ cần được xác định theo yêu cầu nghiệp vụ cụ thể.

Nhận diện vấn đề trong code hiện tại

Giả sử hàm hiện tại có dạng như sau:

<?php
function calculateOrderTotal($items)
{
    $total = 0;

    foreach ($items as $item) {
        if (
            !isset($item['price'], $item['quantity']) ||
            !is_numeric($item['price']) ||
            !is_numeric($item['quantity']) ||
            $item['price'] < 0 ||
            $item['quantity'] < 0
        ) {
            throw new InvalidArgumentException(
                'Du lieu san pham khong hop le'
            );
        }

        $total += $item['price'] * $item['quantity'];
    }

    return $total;
}

Hàm này tương đối ngắn nên chưa nhất thiết phải refactor. Tuy nhiên, khi yêu cầu xử lý mở rộng thêm quy tắc giảm giá, phí vận chuyển, thuế hoặc nhiều loại sản phẩm, hàm có thể ngày càng phức tạp.

Vấn đề cần chú ý không đơn thuần là số dòng code, mà là các trách nhiệm có thể phát triển độc lập đang được đặt chung một chỗ. Khi quy tắc kiểm tra dữ liệu thay đổi, lập trình viên có thể phải chỉnh sửa ngay trong hàm tính tổng. Khi cách tính giá thay đổi, phần xử lý vòng lặp cũng có thể bị ảnh hưởng.

Trong trường hợp này, Vibe Coding có thể được sử dụng để đánh giá xem việc tách trách nhiệm có thực sự mang lại lợi ích hay không. Không nên mặc định rằng mọi hàm đều cần chia nhỏ, bởi việc tạo quá nhiều hàm phụ cũng có thể khiến luồng xử lý khó theo dõi.

Viết prompt yêu cầu phân tích trước khi refactor

Thay vì yêu cầu AI viết lại hàm ngay lập tức, hãy bắt đầu bằng một prompt tập trung vào vấn đề cần giải quyết.

Phân tích hàm calculateOrderTotal() trong code PHP hiện tại.

Hãy xác định:
- Những trách nhiệm đang được xử lý trong hàm.
- Các điều kiện đầu vào cần được giữ nguyên.
- Những rủi ro nếu tách phần kiểm tra dữ liệu và tính toán.
- Phương án refactor đơn giản nhất giúp code dễ bảo trì hơn.

Chưa chỉnh sửa code ở bước này.

Không tự ý thay đổi quy tắc tính tiền, kiểu dữ liệu
đầu vào, giá trị trả về hoặc loại ngoại lệ hiện có.

Nếu có điểm nào chưa đủ thông tin, hãy nêu rõ.

Ở bước này, cần kiểm tra xem AI có hiểu đúng hành vi hiện tại hay không. Đặc biệt, hãy chú ý đến cách xử lý dữ liệu thiếu trường, giá trị bằng 0, số âm và ngoại lệ được ném ra khi dữ liệu không hợp lệ.

Ví dụ, nếu AI đề xuất bỏ qua sản phẩm có dữ liệu không hợp lệ thay vì ném ngoại lệ như code cũ, đó không còn là một thay đổi thuần túy về cấu trúc. Hành vi của chương trình đã khác đi và cần được xem xét như một thay đổi nghiệp vụ riêng.

Yêu cầu tách trách nhiệm nhưng giữ nguyên hành vi

Sau khi thống nhất phương án, có thể yêu cầu AI tách phần xác thực sản phẩm thành một hàm riêng. Trong ví dụ này, mục tiêu là giúp hàm tính tổng dễ đọc hơn mà không bổ sung quy tắc mới.

Một phiên bản sau khi refactor có thể được tổ chức như sau:

<?php
function validateOrderItem($item)
{
    if (
        !is_array($item) ||
        !isset($item['price'], $item['quantity']) ||
        !is_numeric($item['price']) ||
        !is_numeric($item['quantity']) ||
        $item['price'] < 0 ||
        $item['quantity'] < 0
    ) {
        throw new InvalidArgumentException(
            'Du lieu san pham khong hop le'
        );
    }
}

function calculateOrderTotal($items)
{
    $total = 0;

    foreach ($items as $item) {
        validateOrderItem($item);

        $total += $item['price'] * $item['quantity'];
    }

    return $total;
}

Trong phiên bản này, phần kiểm tra dữ liệu đã được tách khỏi phần tính tổng. Khi đọc hàm calculateOrderTotal(), lập trình viên có thể nhanh chóng nhận ra luồng xử lý chính mà không phải xem toàn bộ điều kiện xác thực nằm giữa vòng lặp.

Ví dụ cũng bổ sung kiểm tra is_array($item) để tránh truy cập phần tử trên dữ liệu không phải mảng. Tuy nhiên, đây là một điểm cần xem xét cẩn thận khi refactor dự án thực tế: nếu code cũ không xử lý loại dữ liệu này theo cách tương tự, thay đổi có thể ảnh hưởng đến loại lỗi hoặc thời điểm lỗi xuất hiện. Muốn bảo toàn hành vi nghiêm ngặt, cần xác định rõ cách xử lý đầu vào hiện tại trước khi quyết định giữ thay đổi này.

Ngoài ra, ví dụ chưa giải quyết mọi vấn đề có thể có của một hệ thống tính tiền. Chẳng hạn, is_numeric() chấp nhận một số biểu diễn số mà dự án có thể không mong muốn, còn phép tính bằng kiểu số thực có thể không phù hợp với yêu cầu chính xác tiền tệ. Những vấn đề đó cần được đánh giá riêng, không nên tự động gộp vào một lần refactor nếu mục tiêu ban đầu chỉ là tách trách nhiệm.

Viết kiểm thử để xác nhận kết quả không thay đổi

Sau khi refactor, cần kiểm tra cả trường hợp thông thường lẫn trường hợp biên. Với hàm tính tổng đơn hàng, những trường hợp cơ bản có thể bao gồm danh sách rỗng, một sản phẩm hợp lệ, nhiều sản phẩm và dữ liệu không hợp lệ.

Trường hợp Dữ liệu minh họa Kết quả cần xác minh
Danh sách rỗng Mảng không có sản phẩm Trả về 0 theo hành vi của ví dụ.
Một sản phẩm Giá 100, số lượng 2 Tổng bằng 200.
Nhiều sản phẩm Giá 100, số lượng 2; giá 50, số lượng 3 Tổng bằng 350.
Thiếu trường dữ liệu Sản phẩm không có quantity Ném InvalidArgumentException.
Giá trị âm Giá bằng -1 Ném InvalidArgumentException.
Giá trị không phải số Giá bằng chuỗi không biểu diễn số Ném InvalidArgumentException.

Nếu dự án đã có kiểm thử cho hàm cũ, hãy chạy lại những bài kiểm thử đó sau khi refactor. Nếu chưa có, nên bổ sung kiểm thử dựa trên hành vi hiện tại trước khi tiếp tục mở rộng code.

Điểm cần nhớ là một ví dụ refactor thành công không chỉ nằm ở việc hàm mới trông gọn gàng hơn. Kết quả còn phải đáp ứng các yêu cầu nghiệp vụ, có thể kiểm thử và không tạo ra những thay đổi ngoài phạm vi dự kiến.

Cách kiểm tra chất lượng code sau khi AI refactor

Code do AI tạo ra có thể đúng cú pháp nhưng vẫn chứa lỗi logic, làm tăng sự phụ thuộc giữa các module hoặc gây ra vấn đề trong những trường hợp ít gặp. Vì vậy, sau khi refactor, cần đánh giá kết quả bằng nhiều phương pháp thay vì chỉ dựa vào lời giải thích của công cụ.

Đối chiếu hành vi trước và sau thay đổi

Với những hàm quan trọng, nên sử dụng cùng một tập dữ liệu để so sánh kết quả trước và sau khi refactor. Việc đối chiếu cần xem xét không chỉ giá trị trả về mà còn cả ngoại lệ, trạng thái dữ liệu và những tác động phụ liên quan.

Chẳng hạn, một hàm cập nhật thông tin khách hàng có thể trả về cùng một kết quả ở cả hai phiên bản nhưng lại thay đổi cách xử lý khi khách hàng không tồn tại. Nếu chỉ kiểm tra trường hợp thành công, lỗi này có thể không được phát hiện.

Trong các hệ thống xử lý thanh toán, đơn hàng hoặc dữ liệu quan trọng, cần đặc biệt chú ý đến những trường hợp biên và quy tắc nghiệp vụ ít xuất hiện nhưng có ảnh hưởng lớn khi xảy ra sai lệch.

Kiểm tra mức độ phù hợp với kiến trúc hiện tại

Một phương án refactor có thể hợp lý khi xét riêng một hàm nhưng lại không phù hợp với cách tổ chức toàn bộ dự án. Ví dụ, AI có thể tạo thêm một lớp tiện ích mới trong khi hệ thống đã có một module chịu trách nhiệm tương tự.

Trước khi chấp nhận code mới, hãy kiểm tra:

  • Chức năng mới có trùng lặp với thành phần hiện có hay không.
  • Các phụ thuộc có bị mở rộng không cần thiết hay không.
  • Quy ước đặt tên và cách xử lý lỗi có nhất quán với dự án không.
  • Các giao diện mà module khác đang sử dụng có bị thay đổi không.
  • Việc tách lớp hoặc hàm có thực sự làm rõ trách nhiệm hay chỉ chuyển độ phức tạp sang nơi khác.

Không nên tạo thêm lớp, interface hoặc tầng trung gian chỉ vì AI cho rằng đó là cách tổ chức code chuyên nghiệp hơn. Mỗi thành phần mới cần có lý do tồn tại và mang lại lợi ích đủ rõ để bù đắp chi phí bảo trì.

Chạy công cụ kiểm tra tự động phù hợp với dự án

Tùy ngôn ngữ và framework, có thể sử dụng bộ kiểm thử tự động, trình phân tích tĩnh, công cụ kiểm tra kiểu dữ liệu hoặc công cụ định dạng code. Những công cụ này không thay thế việc xem xét logic nghiệp vụ nhưng giúp phát hiện sớm nhiều lỗi phổ biến.

Đối với dự án PHP, có thể sử dụng PHPUnit nếu dự án đã được cấu hình để chạy kiểm thử, PHPStan hoặc Psalm để phân tích tĩnh và PHP_CodeSniffer để kiểm tra quy ước code. Cần sử dụng phiên bản và cấu hình phù hợp với dự án hiện tại thay vì tự ý nâng cấp công cụ trong cùng một đợt refactor.

Đối với dự án JavaScript hoặc TypeScript, có thể sử dụng bộ kiểm thử sẵn có, ESLint và TypeScript compiler nếu dự án đang sử dụng TypeScript. Không phải dự án nào cũng cần cài thêm toàn bộ các công cụ này; hãy ưu tiên những công cụ đã có và mang lại giá trị trực tiếp cho phần code đang thay đổi.

Những sai lầm cần tránh khi dùng Vibe Coding để refactor

Vibe Coding giúp giảm công sức đọc và chỉnh sửa code, nhưng cũng có thể khiến lập trình viên chấp nhận những thay đổi chưa được kiểm chứng nếu quá tin tưởng vào kết quả do AI tạo ra. Những sai lầm dưới đây cần được tránh để quá trình refactor mang lại lợi ích thực tế.

Yêu cầu tối ưu toàn bộ dự án trong một lần

Yêu cầu AI làm sạch toàn bộ codebase có thể dẫn đến hàng loạt thay đổi không liên quan, từ cách đặt tên, cấu trúc thư mục đến việc tổ chức lại các lớp. Khi nhiều thành phần thay đổi đồng thời, việc kiểm tra và hoàn tác sẽ khó khăn hơn.

Giải pháp phù hợp là xác định module có vấn đề rõ ràng, giới hạn phạm vi và triển khai theo từng bước. Khi một phần đã được kiểm tra đầy đủ, mới chuyển sang phần tiếp theo.

Chấp nhận code mới mà không xem xét phần khác biệt

AI có thể thay đổi nhiều chi tiết ngoài mục tiêu ban đầu, chẳng hạn sửa điều kiện kiểm tra, đổi cách xử lý ngoại lệ hoặc loại bỏ một nhánh xử lý hiếm gặp. Nếu chỉ nhìn vào phiên bản cuối cùng, lập trình viên có thể bỏ qua những thay đổi có ảnh hưởng đến nghiệp vụ.

Hãy kiểm tra diff sau mỗi lần chỉnh sửa, yêu cầu AI giải thích các thay đổi quan trọng và từ chối những thay đổi không có căn cứ. Với những thay đổi lớn, nên xem xét từng file thay vì duyệt tất cả cùng một lúc.

Nhầm lẫn giữa refactor và tối ưu hiệu năng

Refactor chủ yếu tập trung vào cấu trúc và khả năng bảo trì, trong khi tối ưu hiệu năng nhằm cải thiện những chỉ số như thời gian xử lý hoặc mức sử dụng bộ nhớ. Hai mục tiêu có thể liên quan nhưng không đồng nghĩa với nhau.

Ví dụ, chuyển một đoạn xử lý thành nhiều hàm nhỏ có thể làm code dễ đọc hơn nhưng không nhất thiết chạy nhanh hơn. Ngược lại, thay đổi cách truy vấn cơ sở dữ liệu có thể cải thiện hiệu năng nhưng cũng làm tăng rủi ro nếu cấu trúc truy vấn và hành vi trả kết quả thay đổi.

Nếu cần tối ưu hiệu năng, hãy xác định vấn đề bằng số liệu đo đạc và thực hiện như một mục tiêu riêng. Không nên chấp nhận những thay đổi phức tạp chỉ vì AI khẳng định rằng chúng sẽ chạy nhanh hơn khi chưa có căn cứ kiểm chứng.

Bỏ qua các phụ thuộc và tác động bên ngoài

Một hàm có thể được sử dụng bởi nhiều module, API hoặc tác vụ chạy nền. Việc đổi tên phương thức, thay đổi tham số hoặc sửa cấu trúc dữ liệu trả về có thể khiến các thành phần phụ thuộc không còn hoạt động đúng.

Trước khi refactor, hãy xác định những nơi sử dụng thành phần cần thay đổi. Nếu một giao diện công khai thực sự cần thay đổi, hãy đánh giá riêng mức độ tương thích và kế hoạch cập nhật các thành phần liên quan.

Với hệ thống có tích hợp bên ngoài, cần chú ý đến những tác động như gửi email, cập nhật dữ liệu, gọi dịch vụ thanh toán hoặc phát sinh tác vụ nền. Những hành vi này cần được kiểm tra cẩn thận, không chỉ dựa trên kết quả trả về của hàm.

Để AI tự sửa lỗi liên tục mà không xác định nguyên nhân

Khi kiểm thử thất bại, yêu cầu AI sửa lại ngay mà không cung cấp thông tin về lỗi có thể khiến công cụ thực hiện thêm những thay đổi thiếu định hướng. Một lỗi ban đầu nhỏ có thể dẫn đến nhiều chỉnh sửa nối tiếp nhau và làm tăng độ phức tạp của việc khắc phục.

Cách làm tốt hơn là cung cấp thông báo lỗi, kết quả kiểm thử, đoạn code liên quan và mô tả hành vi mong đợi. Trước tiên, yêu cầu AI giải thích nguyên nhân có khả năng xảy ra và đề xuất cách kiểm chứng. Sau khi xác định được vấn đề, mới thực hiện thay đổi nhỏ nhất có thể để xử lý nó.

Khi nào nên và không nên dùng Vibe Coding để refactor?

Không phải mọi công việc refactor đều phù hợp với mức độ tự động hóa như nhau. Việc lựa chọn phạm vi phù hợp giúp tận dụng khả năng phân tích của AI mà vẫn duy trì quyền kiểm soát đối với những phần quan trọng của hệ thống.

Tình huống Mức độ phù hợp Cách tiếp cận
Tách hàm dài, đổi tên biến hoặc làm rõ điều kiện Phù hợp Yêu cầu thay đổi nhỏ và kiểm tra lại hành vi.
Tìm và xử lý code trùng lặp Phù hợp nếu đã xác minh logic tương đương So sánh quy tắc nghiệp vụ trước khi đưa code vào dùng chung.
Refactor module chưa có nhiều kiểm thử Cần thận trọng Xác định hành vi hiện tại và bổ sung kiểm thử trước khi sửa.
Thay đổi kiến trúc của hệ thống lớn Cần kiểm soát chặt chẽ Phân tích phụ thuộc, lập kế hoạch và triển khai theo từng giai đoạn.
Thay đổi logic thanh toán hoặc phân quyền Rủi ro cao Giữ phạm vi nhỏ, yêu cầu kiểm thử chuyên biệt và đánh giá thủ công.
Refactor khi chưa hiểu rõ hành vi của code cũ Chưa nên thực hiện ngay Ưu tiên tìm hiểu luồng xử lý và làm rõ yêu cầu trước.

Đặc biệt, với những hệ thống đang vận hành và có dữ liệu quan trọng, cần xem xét thêm phương án sao lưu, khả năng khôi phục, môi trường thử nghiệm và quy trình triển khai. AI có thể hỗ trợ phân tích và viết code nhưng không thay thế trách nhiệm đánh giá rủi ro của người phát triển.

Kinh nghiệm để refactor bằng AI hiệu quả và dễ bảo trì

Để đạt kết quả tốt, nên xem Vibe Coding là một phương pháp phối hợp giữa lập trình viên và AI thay vì giao toàn bộ quyết định cho công cụ. AI đảm nhận những công việc phù hợp như đọc code, phát hiện điểm bất hợp lý, đề xuất phương án và hỗ trợ triển khai; lập trình viên chịu trách nhiệm xác định yêu cầu, đánh giá tác động và xác nhận tính đúng đắn.

  • Bắt đầu từ vấn đề thực tế: Ưu tiên những đoạn code thường xuyên phát sinh lỗi, khó sửa hoặc cản trở việc phát triển tính năng.
  • Cung cấp đủ ngữ cảnh: Cho AI biết quy ước của dự án, các phụ thuộc và hành vi cần giữ nguyên.
  • Giữ mỗi lần thay đổi nhỏ: Giúp dễ kiểm tra, dễ xác định nguyên nhân và dễ hoàn tác khi cần.
  • Yêu cầu giải thích thay đổi: Đặc biệt với những phần liên quan đến luồng dữ liệu, ngoại lệ và giao diện giữa các module.
  • Duy trì kiểm thử: Dùng kiểm thử tự động và kiểm tra thủ công phù hợp với mức độ rủi ro.
  • Không chạy theo code đẹp về hình thức: Ưu tiên sự rõ ràng, nhất quán và phù hợp với nhu cầu bảo trì thực tế.
  • Bảo vệ thông tin dự án: Kiểm tra chính sách xử lý dữ liệu của công cụ AI trước khi gửi mã nguồn độc quyền, thông tin xác thực hoặc dữ liệu nhạy cảm.
  • Lưu lại các mốc thay đổi: Sử dụng Git và các commit có phạm vi rõ ràng để theo dõi tiến trình, so sánh và khôi phục khi cần.

Ngoài ra, không nên đánh giá hiệu quả refactor chỉ bằng số dòng code đã giảm hoặc số file đã được chỉnh sửa. Những chỉ số hữu ích hơn là mức độ dễ hiểu của code, khả năng kiểm thử, số lượng logic trùng lặp thực sự được loại bỏ và mức độ thuận tiện khi thực hiện những thay đổi tiếp theo.

Kết luận

Cách dùng Vibe Coding để refactor mã nguồn hiệu quả là xác định đúng vấn đề, yêu cầu AI phân tích trước khi chỉnh sửa, giới hạn phạm vi thay đổi và kiểm tra kết quả sau từng bước. Phương pháp này giúp lập trình viên tận dụng khả năng đọc hiểu và hỗ trợ viết code của AI mà không phải đánh đổi tính ổn định của hệ thống.

Điều quan trọng nhất là giữ nguyên hành vi nghiệp vụ khi mục tiêu chỉ là cải thiện cấu trúc. Một đoạn code mới chỉ thực sự tốt hơn khi dễ đọc, dễ bảo trì, phù hợp với kiến trúc dự án và đã được kiểm chứng bằng những phương pháp phù hợp.

Đối với các dự án PHP và website đang vận hành, Web Mới khuyến nghị bắt đầu với những hàm hoặc module có phạm vi rõ ràng, sử dụng Git để kiểm soát thay đổi và duy trì kiểm thử trong suốt quá trình. Khi kết hợp Vibe Coding với quy trình kiểm soát chất lượng hợp lý, lập trình viên có thể cải thiện mã nguồn từng bước, giảm rủi ro và tạo nền tảng thuận lợi hơn cho việc phát triển lâu dài.

  • ★★★★★ ★★★★★
  • 0 Bình luận
CEO Bùi Tấn Lực | Founder Web Mới
Bùi Tấn Lực
Tìm hiểu về CEO Bùi Tấn Lực, Founder Web Mới với nhiều năm kinh nghiệm trong lĩnh vực phát triển website, SEO và chia sẻ kiến thức công nghệ
Đánh giá
Chia sẻ nội dung đánh giá của bạn về Cách dùng Vibe Coding để refactor mã nguồn
Email, Điện thoại của bạn sẽ không được hiển thị công khai. Các trường bắt buộc được đánh dấu *
Đánh giá của bạn
Tên *
Email
Số điện thoại *
Bình luận, Hỏi đáp
Yêu Cầu Báo Giá
Gửi trang web mẫu cần làm theo, chúng tôi sẽ báo giá đến bạn từ Email (tanlucit09@gmail.com - Bùi Tấn Lực) hoặc Zalo (Lực IT - 0398259259) !