Login

Refactoring an toàn: cải thiện code từng bước nhỏ mà không làm hỏng

  • author-image

    Nguyễn Đình Cường

  • blog-tag
  • blog-comment 0 comment
  • created-date 09 Nov, 2026
blog-thumbnail

Refactoring là việc cải thiện cấu trúc bên trong của code mà không thay đổi hành vi bên ngoài. Nghe đơn giản nhưng nhiều người ngại vì sợ sửa xong thì hỏng. Thực ra, nếu làm theo từng bước nhỏ và có lưới an toàn, refactor là một trong những việc ít rủi ro nhất và có lợi nhất.

Refactor là gì và không là gì

Refactor không phải là thêm tính năng, cũng không phải sửa lỗi. Nó chỉ làm cho code dễ đọc, dễ mở rộng hơn: đổi tên, tách hàm, loại bỏ lặp, đơn giản hóa điều kiện. Quy tắc cốt lõi: đầu vào và đầu ra của hệ thống phải y nguyên trước và sau khi refactor.

Vì vậy hãy tách bạch hai việc: khi đang thêm tính năng thì không refactor lớn, và khi refactor thì không thêm tính năng. Làm lẫn hai việc, nếu có lỗi bạn không biết do đâu.

Lưới an toàn: test trước, refactor sau

Trước khi đụng vào code, hãy chắc rằng bạn có cách kiểm tra hành vi vẫn đúng:

  • Có unit test sẵn thì chạy chúng.
  • Chưa có test thì viết vài test mô tả hành vi hiện tại (kể cả khi hành vi đó chưa hoàn hảo), được gọi là characterization test.
  • Với code khó test, ít nhất hãy ghi lại cách chạy thủ công và kết quả mong đợi.

Các bước nhỏ, chạy test sau mỗi bước

Nguyên tắc vàng là mỗi bước đủ nhỏ để nếu hỏng, bạn biết ngay vì sao. Một nhịp làm việc điển hình:

  1. Chạy test, chắc chắn tất cả đang xanh.
  2. Thực hiện một thay đổi nhỏ (một lần đổi tên, một lần tách hàm).
  3. Chạy test lại.
  4. Xanh thì commit, đỏ thì hoàn tác (git checkout . hoặc Ctrl+Z) và thử cách khác.
  5. Lặp lại.

Ví dụ: đơn giản hóa điều kiện lồng nhau

Đoạn code trước khi refactor:

function getShippingFee(order) {if (order !== null) {if (order.total > 500000) {return 0;} else {if (order.isRemote) {return 50000;} else {return 30000;}}} else {return 0;}}

Sau khi refactor từng bước (guard clause, bỏ else thừa, đặt hằng số có tên):

const FREE_SHIPPING_THRESHOLD = 500000;const REMOTE_FEE = 50000;const STANDARD_FEE = 30000;function getShippingFee(order) {if (order === null) return 0;if (order.total > FREE_SHIPPING_THRESHOLD) return 0;return order.isRemote ? REMOTE_FEE : STANDARD_FEE;}

Hành vi giữ nguyên nhưng đọc gọn và rõ hơn nhiều. Các giá trị 500000, 50000, 30000 giờ có tên để người đọc hiểu ý nghĩa.

Các thủ thuật refactor phổ biến

Kỹ thuậtKhi nào dùng
Rename (đổi tên)Tên biến, hàm không nói lên ý nghĩa
Extract FunctionHàm dài, một đoạn code làm việc riêng
InlineHàm hoặc biến tạm không đem lại giá trị
Replace Magic NumberCon số hoặc chuỗi xuất hiện không rõ nghĩa
Introduce Parameter ObjectHàm có quá nhiều tham số đi cùng nhau
Remove Dead CodeCode không bao giờ được gọi

Hãy tận dụng chức năng refactor tự động của IDE (rename, extract, move). Chúng cập nhật mọi nơi tham chiếu nên ít sai sót hơn sửa tay.

Khi nào nên và không nên refactor

  • Nên: ngay trước khi thêm tính năng vào đoạn code khó hiểu ("làm cho thay đổi dễ, rồi làm thay đổi dễ đó"); khi review phát hiện đoạn code lặp; khi bạn vừa hiểu ra một khái niệm và muốn code phản ánh nó.
  • Không nên: khi sắp đến hạn chót và code đó sắp bị bỏ; khi chưa hiểu code làm gì; khi không có cách kiểm tra nào; khi định "viết lại toàn bộ" thay vì cải thiện dần.

Làm việc cùng team

Commit refactor riêng biệt với commit thay đổi hành vi, và ghi rõ trong message (ví dụ "refactor: tách hàm tính phí vận chuyển"). Người review sẽ dễ dàng hơn vì biết chỉ cần kiểm tra là hành vi không đổi. Tránh gộp refactor khổng lồ vào một pull request lớn, hãy chia nhỏ.

Kết luận

Refactoring không phải một dự án riêng cần xin phép, mà là thói quen nhỏ hằng ngày: để lại code sạch hơn một chút so với lúc bạn tìm thấy nó. Có test, bước nhỏ, commit thường xuyên là đủ để làm việc này một cách tự tin.

Nếu bạn muốn rèn kỹ năng đọc hiểu và cải thiện code qua các dự án thực hành, hãy xem qua các khóa học tại codebem.com.

author_photo
Nguyễn Đình Cường

0 comment