Mục lục · 7 phần
Trả lời nhanh
Refactor là sắp xếp lại mã bên trong công cụ mà không thay đổi công việc nó thực hiện bên ngoài. Tool chạy được hôm nay chưa có nghĩa là mã dễ hiểu hoặc sửa một chỗ không làm hỏng chỗ khác. Anh/chị vẫn nhận báo cáo hay lọc đơn như trước, còn phần mã được viết rõ hơn để phục vụ lần sửa sau.
Refactor là việc sắp xếp lại phần mã bên trong một tool mà không đổi việc tool phải làm ở bên ngoài. Tool vẫn gửi báo cáo, lọc đơn hay cập nhật tồn kho như trước, nhưng phần nền được viết rõ ràng hơn để lần sau sửa không vỡ dây chuyền.
Tool chạy được rồi, vì sao vẫn cần refactor?
Một tool “chạy được” mới trả lời câu hỏi đầu tiên: nó có làm ra kết quả hôm nay không. Nó chưa trả lời các câu khác: tuần sau thêm một cột dữ liệu có sửa nổi không, người khác mở vào có hiểu không, hay sửa một chỗ lại làm hỏng việc khác.
Ví dụ, anh/chị nhờ AI làm tool lấy đơn Shopee rồi gửi bảng tổng hợp vào buổi sáng. Bản đầu có thể làm đúng cả ba việc: đăng nhập, lấy đơn và gửi tin nhắn. Sau đó anh/chị muốn thêm dòng tách đơn hoàn. Nếu toàn bộ việc nằm trong một đoạn mã dài, AI phải lần tìm trong cả đoạn để sửa. Nếu phần lấy dữ liệu, phần tính toán và phần gửi tin được tách riêng, yêu cầu mới chỉ chạm vào đúng phần cần đổi.
Refactor không phải làm tool có thêm tính năng. Nó là dọn đường cho tính năng sẽ đến sau. Hãy hình dung một kệ kho đang dùng được, nhưng hàng mới, hàng hoàn và hàng chờ đóng gói bị để lẫn nhau. Sắp lại nhãn kệ không làm tăng số đơn ngay trong ngày. Đổi lại, lần sau cần tìm một món, người làm không phải lục cả kho.
Điểm quan trọng là chức năng cũ phải giữ nguyên sau khi refactor. Tool từng gửi file đúng lúc nào thì sau khi sửa vẫn phải gửi file đúng lúc đó. Nếu nhân dịp dọn mã mà anh/chị đổi luôn cách tính doanh thu, đổi màn hình và đổi luồng duyệt đơn, đó không còn là một việc refactor thuần túy. Đó là vừa sửa cấu trúc vừa thay đổi nghiệp vụ, nên rủi ro cao hơn nhiều.
Dấu hiệu nào cho thấy mã đang làm anh/chị chậm lại?
Dấu hiệu dễ thấy nhất là mỗi yêu cầu nhỏ đều biến thành một cuộc sửa lớn. Anh/chị chỉ muốn đổi tên một cột trong báo cáo, nhưng AI lại sửa nhầm cả phần xuất file. Hoặc anh/chị muốn thêm một kênh quảng cáo, nhưng tool bắt đầu báo lỗi ở phần lấy dữ liệu đơn hàng vốn không liên quan. Những tình huống này thường xuất hiện khi các phần việc bị quấn vào nhau.
Dấu hiệu thứ hai là cùng một quy tắc được chép lại ở nhiều chỗ. Chẳng hạn tool kiểm tra mã đơn trống ở ba màn hình khác nhau. Mỗi nơi đều có một đoạn gần giống nhau: nếu thiếu mã thì báo lỗi, nếu có thì tiếp tục. Khi quy tắc đổi, anh/chị phải nhớ sửa đủ ba chỗ. Chỉ sót một chỗ là kết quả đã không đồng nhất.
Dấu hiệu thứ ba là AI cần được nhắc lại quá nhiều bối cảnh mỗi lần sửa. Nếu anh/chị luôn phải nói “đừng đụng vào phần gửi báo cáo”, “phần này dùng cho đơn hoàn”, “đoạn kia đang tính phí”, có thể code chưa thể hiện ranh giới công việc rõ ràng. Mã rõ không làm anh/chị thành lập trình viên. Nó giúp anh/chị mô tả đúng chỗ cần thay đổi cho AI.
Một dấu hiệu khác là lỗi khó truy vết. Tool báo tổng tiền không khớp nhưng không biết nó sai khi lấy dữ liệu, khi lọc đơn hay khi cộng tiền. Trong mã có cấu trúc tốt, mỗi bước để lại kết quả riêng để kiểm tra. Khi tổng tiền sai, anh/chị có thể hỏi AI kiểm tra từng bước thay vì yêu cầu “xem lại toàn bộ tool”.
Refactor khác gì sửa lỗi và thêm tính năng?
Ba việc này hay bị gọi chung là “sửa tool”, nhưng chúng khác nhau. Sửa lỗi là đưa kết quả sai về đúng. Thêm tính năng là làm tool được việc mà trước đó nó chưa làm. Refactor là giữ kết quả bên ngoài như cũ rồi đổi cách tổ chức bên trong.
Bảng đối chiếu Sửa lỗi (Fix bug), Thêm tính năng (Feature) và Tối ưu cấu trúc (Refactor) theo 3 tiêu chí.
Ví dụ, tool tính chiết khấu cho đại lý đang trả về 900.000đ trong khi quy tắc của shop là đơn 10.000.000đ được chiết khấu 10%, tức phải là 1.000.000đ. Đây là sửa lỗi tính toán, vì con số đầu ra đang sai. Nếu tool trước đây chỉ tính chiết khấu mà nay anh/chị muốn nó tự tạo file đối soát, đây là thêm tính năng. Còn nếu tool vẫn trả đúng 1.000.000đ nhưng AI chuyển phần tính chiết khấu ra một hàm riêng để những màn hình khác dùng lại, đó là refactor.
Phân biệt ba việc này giúp anh/chị giao việc đúng hơn. Khi yêu cầu AI refactor, hãy nói rõ: “Giữ nguyên đầu vào, đầu ra và các quy tắc đang chạy. Chỉ tách phần kiểm tra đơn, phần tính tiền và phần xuất báo cáo.” Câu này làm AI ít có cớ tự ý đổi logic kinh doanh.
Anh/chị cũng nên tách bước kiểm tra ra sau mỗi lần refactor. Lấy vài trường hợp tool từng xử lý đúng để chạy lại. Ví dụ một đơn 10.000.000đ với chiết khấu 10% phải tiếp tục cho ra 1.000.000đ; đơn không có mã hàng vẫn phải bị báo thiếu mã nếu đó là quy tắc cũ. Kiểm tra bằng những tình huống quen thuộc giúp phát hiện việc mã đã gọn hơn nhưng hành vi lại lệch đi.
Những phần nào nên tách riêng trước?
Đừng bắt đầu bằng mục tiêu mơ hồ như “làm code thật đẹp”. Hãy bắt đầu ở chỗ gây khó cho việc vận hành. Với tool dành cho shop, ba phần thường đáng tách là dữ liệu vào, quy tắc xử lý và kết quả gửi ra.
Phần dữ liệu vào là nơi tool đọc file Excel, nhận dữ liệu từ một endpoint hoặc lấy thông tin từ form. Nó chỉ nên chịu trách nhiệm nhận dữ liệu và báo rõ nếu dữ liệu thiếu. Phần này không nên vừa đọc file vừa tính giá bán vừa gửi tin nhắn. Khi nguồn dữ liệu đổi định dạng, anh/chị sẽ biết chính xác phần nào cần cập nhật.
Phần xử lý là nơi đặt quy tắc kinh doanh. Ví dụ, đơn có giá 10.000.000đ và mức chiết khấu 10% thì tiền chiết khấu là 1.000.000đ. Nếu có yêu cầu tính phí giao hàng, quy tắc đó cũng nên nằm ở đây, thay vì rải trong giao diện hoặc đoạn gửi báo cáo. Nhờ vậy, khi cần kiểm tra vì sao ra một con số, AI có một nơi rõ ràng để đối chiếu.
Phần kết quả gửi ra là bảng, file, tin nhắn hay màn hình mà người dùng nhìn thấy. Nó nhận con số đã tính xong rồi trình bày lại. Khi anh/chị đổi từ gửi tin nhắn sang xuất file, phần tính toán không cần bị viết lại. Đây là lợi ích thiết thực nhất của việc chia phần: thay một đầu việc không kéo theo việc sửa tất cả đầu việc còn lại.
Một tình huống dễ gặp khi dùng AI làm tool
Anh/chị có một tool gửi báo cáo doanh thu mỗi sáng. Ban đầu chỉ có một nguồn đơn nên AI viết tất cả trong một file: lấy dữ liệu, bỏ đơn huỷ, cộng doanh thu rồi gửi email. Vài lần cập nhật sau, tool có thêm đơn hoàn, mã giảm giá và bảng theo sản phẩm. Mỗi tính năng đều có lý do, nhưng các đoạn thêm vào nằm xen kẽ nên người viết sau khó biết đoạn nào đang tác động đến đoạn nào.
Trong tình huống này, refactor không cần một câu chuyện “đập đi làm lại”. Anh/chị có thể yêu cầu AI vẽ lại luồng hiện tại bằng lời dễ hiểu trước: dữ liệu đi vào từ đâu, điều kiện nào loại đơn, công thức nào tạo tổng và kết quả được gửi ở đâu. Sau đó yêu cầu tách từng phần nhưng không đổi kết quả. Làm từng phần giúp anh/chị còn kiểm soát được tool đang giữ nguyên việc cũ.
Người mới thường hiểu nhầm rằng mã ngắn hơn luôn tốt hơn. Không hẳn. Một đoạn mã ngắn nhưng gộp nhiều việc vẫn khó sửa. Mục tiêu là mỗi phần có nhiệm vụ dễ nói thành câu. “Đoạn này đọc đơn.” “Đoạn này kiểm tra đơn hợp lệ.” “Đoạn này tính tổng.” Khi mô tả được như vậy, anh/chị có thể yêu cầu AI sửa chính xác hơn và dễ tự kiểm tra hơn.
Kinh nghiệm thực tế hữu ích nhất ở đây là không refactor bằng cảm giác. Hãy ghi ra vài kết quả mà tool đang phải giữ nguyên, rồi dùng chúng làm bài kiểm tra sau khi sửa. Nếu tool đang phục vụ luồng có tiền, tồn kho hoặc đơn hàng, hãy dùng bản sao để thử trước. Việc lưu các lần thay đổi bằng git và github cũng giúp anh/chị quay lại phiên bản trước nếu bản mới có lỗi.
Khi nào chưa nên refactor?
Không phải tool nào cũng cần dọn mã. Một đoạn script dùng một lần để lọc danh sách quà tặng có thể làm xong rồi bỏ. Đầu tư thời gian sắp xếp cấu trúc cho nó thường không đem lại lợi ích tương xứng. Refactor đáng làm khi tool sẽ còn chạy lặp lại, còn có người sửa tiếp hoặc còn được thêm chức năng.
Anh/chị cũng chưa nên refactor khi quy trình kinh doanh chưa chốt. Ví dụ hôm nay đội vận hành muốn đơn hoàn được tính theo một cách, ngày mai lại đổi sang cách khác. Nếu vội tách mã theo quy tắc chưa ổn định, AI có thể làm rất kỹ một cấu trúc mà vài ngày sau phải thay lại. Hãy chốt trước điều tool cần làm; sau đó mới dọn cách nó được viết.
Đừng dùng refactor để che một lỗi chưa hiểu. Nếu số liệu sai, hãy xác định quy tắc nào sai và sửa đúng quy tắc đó trước. Refactor có thể làm code dễ đọc hơn để tìm lỗi, nhưng nó không tự biến công thức sai thành đúng. Với những tool quan trọng, hãy yêu cầu AI nêu rõ phần nào chỉ đổi cấu trúc, phần nào đổi hành vi, và kiểm tra hai phần đó riêng.
Refactor là một phần của việc áp dụng hiệu quả tư duy lập trình bằng AI vào vận hành kinh doanh. Anh/chị không cần hiểu hết cú pháp. Điều anh/chị cần giữ là mục tiêu kinh doanh, các kết quả đúng phải được bảo toàn và quyền quyết định trước khi đưa bản sửa vào dùng thật.
Câu hỏi thường gặp
Refactor có làm tool đang chạy bị dừng không?
Có thể, nếu anh/chị sửa trực tiếp trên bản đang dùng. Hãy sao chép dự án, refactor trên bản sao và chạy lại các tình huống cũ trước. Khi kết quả giữ nguyên, anh/chị mới thay bản chính.
Tôi không biết code thì yêu cầu AI refactor thế nào?
Anh/chị hãy nêu chức năng cần giữ nguyên trước, rồi chỉ ra chỗ đang khó thay đổi. Ví dụ: “Tool vẫn phải lọc đơn huỷ và gửi báo cáo; hãy tách phần đọc dữ liệu, phần tính tổng và phần gửi email.” Sau đó yêu cầu AI giải thích vai trò từng phần bằng tiếng Việt dễ hiểu.
Refactor có phải là viết lại tool từ đầu không?
Không. Viết lại từ đầu thường có nguy cơ đổi cả hành vi và bỏ sót tính năng cũ. Refactor tốt tận dụng phần đang đúng, chỉ sắp lại để mã dễ đọc, dễ kiểm tra và dễ mở rộng.
Tool tính tiền sai thì refactor trước hay sửa lỗi trước?
Sửa lỗi tính tiền trước, vì đầu ra đúng là điều cần bảo vệ. Ví dụ đơn 10.000.000đ chiết khấu 10% phải ra 1.000.000đ, không phải 900.000đ. Sau khi công thức đúng và có ví dụ kiểm tra, anh/chị mới refactor để công thức nằm ở chỗ dễ quản lý hơn.
Khi nào tool nhỏ cũng nên refactor?
Tool nhỏ nên refactor khi nó bắt đầu được dùng lặp lại hoặc phát sinh nhiều yêu cầu vá thêm. Nếu mỗi lần thêm một cột báo cáo đều làm anh/chị lo sẽ hỏng phần cũ, đó là lúc cấu trúc cần được dọn. Còn script làm một lần rồi xoá thì thường chưa cần.
Refactor xong, tôi kiểm tra những gì trước khi dùng thật?
Kiểm tra những kết quả cũ quan trọng nhất: dữ liệu có vào đủ không, điều kiện loại đơn có giữ nguyên không và tổng tiền có khớp không. Với ví dụ đơn 10.000.000đ chiết khấu 10%, kết quả phải vẫn là 1.000.000đ. Sau đó kiểm tra việc gửi file, email hoặc tin nhắn ở môi trường thử trước khi đưa vào luồng đang vận hành.
Git và GitHub giúp gì khi refactor tool?
Git ghi lại từng lần thay đổi của mã; GitHub là nơi thường dùng để lưu và chia sẻ lịch sử đó. Trước khi AI sửa cấu trúc, anh/chị lưu một mốc đang chạy được. Nếu bản refactor phát sinh lỗi, anh/chị có điểm để đối chiếu hoặc quay lại thay vì phải nhớ từng dòng cũ.
Để xem cách lưu phiên bản dự án và các khái niệm liên quan, anh/chị có thể tham khảo GitHub Docs.
