Refactor là gì, làm sao chắc rằng sau khi refactor code vẫn chạy y như cũ?

Người phỏng vấn muốn biết bạn có phân biệt được sửa cấu trúc với sửa hành vi không, và bạn có thói quen tự bảo vệ mình bằng test không. Refactor là thay đổi cấu trúc bên trong của code để dễ đọc, dễ sửa hơn mà không đổi hành vi bên ngoài. Đổi tên biến, tách một hàm dài thành các hàm nhỏ, gom đoạn code lặp vào một chỗ đều là refactor. Thêm tính năng hay sửa lỗi thì không phải, vì chúng đổi hành vi.

Cách trả lời tốt đi theo thứ tự này:

1. Có test trước khi động vào code. Nếu code chưa có test, viết test đặc tả: một test chụp lại code đang làm gì, kể cả khi hành vi đó hơi kỳ. Nó không hỏi "đúng hay sai", chỉ hỏi "sau khi sửa có khác trước không".
2. Đi từng bước nhỏ, chạy test sau mỗi bước. Test đỏ thì biết ngay bước nào vừa gây ra, vì chỉ có một thay đổi nhỏ.
3. Không trộn refactor với sửa hành vi. Nếu thấy một lỗi giữa chừng, ghi lại và sửa ở commit riêng. Tách commit đổi tên khỏi commit di chuyển code cũng giúp người review đọc nhanh hơn.
4. Biết cái gì là "tên bên trong", cái gì là "tên bên ngoài". Đổi tên một biến cục bộ thì an toàn. Đổi tên một trường trong JSON mà API trả về thì làm hỏng mọi nơi đang đọc trường đó, dù code của bạn vẫn biên dịch được.

Ví dụ cụ thể giúp câu trả lời thuyết phục hơn. Chẳng hạn bạn đang dọn một máy chủ nhỏ trả danh sách đơn hàng. Bạn đổi trường khach thành customer cho nhất quán với phần còn lại, và test đặc tả kiểm tra phản hồi của máy chủ lập tức đỏ, vì trang quản lý đang đọc đúng trường khach. Không có test đó thì lỗi chỉ lộ ra khi người dùng thấy cột trống.

Điểm cộng: nói rõ khi nào bạn không refactor, ví dụ khi sắp có deadline mà code đó không phải chỗ đang sửa, hoặc khi chưa thể viết test cho nó. Refactor đúng lúc, trong phạm vi nhỏ, hợp với một pull request dễ review hơn là dọn cả dự án trong một lần.