Wavi Books · Kỹ nghệ phần mềm & Clean Code

Refactoring là gì? Cách cải tiến code mà không làm đổi hành vi

Nguyễn Minh Trí · Biên tập chuyên môn Wavi Books

Refactoring là gì, code smell, kỹ thuật cải tiến cấu trúc mã nguồn và quy trình refactor an toàn với kiểm thử tự động.

## Refactoring là gì

## Điều đáng nhớ trước khi áp dụng nguyên tắc

Refactoring là gì, code smell, kỹ thuật cải tiến cấu trúc mã nguồn và quy trình refactor an toàn với kiểm thử tự động. Mục tiêu không phải làm code trông đẹp hơn, mà là giúp con người hiểu và thay đổi phần mềm an toàn hơn.

Một đoạn code không có bug vẫn có thể khiến cả đội sợ thay đổi. Tên biến mơ hồ, hàm quá dài và test thiếu khiến mỗi lần sửa giống như dò mìn. Khi đó, chất lượng code không còn là chuyện thẩm mỹ; nó trở thành thời gian, rủi ro và chi phí thật của dự án.

Có những đoạn code ai cũng ngại chạm vào vì chỉ một thay đổi nhỏ có thể kéo theo lỗi ở nơi không ngờ tới. Refactoring là cách trả lại sự tự tin ấy từng bước một.

Refactoring là thay đổi cấu trúc bên trong của code mà không làm thay đổi hành vi quan sát được. Mục tiêu là tăng khả năng đọc, sửa đổi và kiểm thử, không phải viết lại toàn bộ hệ thống.

Refactor nên diễn ra theo bước nhỏ, có test bảo vệ và commit dễ hoàn tác. Code smell là tín hiệu để điều tra, không phải mệnh lệnh áp dụng mọi mẫu thiết kế.

## Những khái niệm cốt lõi cần nắm

## Dọn đường trước khi chạy nhanh hơn

Refactoring thay đổi cấu trúc bên trong nhưng giữ nguyên hành vi nhìn từ bên ngoài. Bạn có thể đổi tên, tách hàm, giảm lặp hoặc phân chia trách nhiệm để code dễ hiểu và dễ sửa hơn.

## Chuyện gì xảy ra khi đem vào dự án thật?

Sai lầm phổ biến là vừa refactor vừa thêm tính năng lớn. Khi kết quả thay đổi, team khó biết lỗi đến từ yêu cầu mới hay từ việc tổ chức lại code.

## Nếu bắt đầu hôm nay, tôi sẽ làm thế này

Hãy có kiểm thử đủ bảo vệ, thực hiện thay đổi nhỏ và commit thường xuyên. Refactoring tốt thường không ồn ào; nó khiến lần thay đổi tiếp theo bớt căng thẳng.

- Rename làm rõ ý định.

- Extract Function tách trách nhiệm.

- Remove Duplication giảm nhiều nguồn sự thật.

- Replace Conditional làm rõ logic phức tạp.

## Lộ trình thực hành từng bước

- Bước 1: Khóa hành vi bằng test hoặc characterization test.

- Bước 2: Thay đổi một bước nhỏ và chạy test.

- Bước 3: Review độ dễ hiểu, hiệu năng và commit độc lập.

## Những sai lầm thường gặp

- Trộn refactor với thay đổi tính năng lớn.

- Tối ưu kiến trúc khi chưa hiểu nghiệp vụ.

- Dùng chỉ số độ phủ test thay cho chất lượng test.

## Góc nhìn dành cho người học và developer Việt Nam

Trong đội phần mềm Việt Nam, nên dành refactor cho vùng code thay đổi thường xuyên và gắn với mục tiêu giảm lỗi hoặc rút ngắn thời gian phát triển.

## Nên học tiếp như thế nào?

## Bài tập refactor không đổi hành vi

Chọn một hàm dài trong dự án, viết vài test bảo vệ đầu vào quan trọng rồi lưu lại phiên bản ban đầu. Thực hiện từng thay đổi nhỏ: đổi tên, tách hàm và giảm lặp. Chạy test sau mỗi bước và so sánh mức độ dễ đọc trước, sau. Nếu bạn phải sửa cả test chỉ vì đổi cấu trúc bên trong, hãy xem lại test có đang bám quá chặt vào cách cài đặt hay không. Cuối cùng, nhờ một đồng đội đọc hai phiên bản mà không giải thích trước để kiểm tra thay đổi có thực sự làm ý định rõ hơn.

## Ví dụ xuyên suốt để nối kiến thức

Một hàm tạo hóa đơn vừa tính giảm giá, gọi database, gửi email và định dạng PDF. Mỗi yêu cầu mới khiến team sửa cùng một nơi và test rất chậm. Refactoring có thể tách phép tính thuần, cổng dữ liệu và tác dụng phụ mà vẫn giữ kết quả người dùng nhìn thấy.

## Khung triển khai từ thử nghiệm đến thực tế

Nên refactor khi code cản trở thay đổi sắp tới, lỗi lặp ở cùng khu vực hoặc thời gian đọc hiểu vượt thời gian sửa. Không cần dọn toàn bộ hệ thống; hãy cải thiện vùng đang có lý do kinh doanh để chạm vào.

### Bốn bước nên đi theo thứ tự

- Mô tả hành vi hiện tại và thêm characterization test nếu thiếu.

- Chọn một code smell cụ thể thay vì mục tiêu mơ hồ làm sạch code.

- Thay đổi nhỏ, chạy test và commit sau mỗi trạng thái an toàn.

- Đo lại mức dễ đọc và tốc độ thực hiện yêu cầu kế tiếp.

## Trade-off cần nhìn thẳng

Refactor không có test làm rủi ro tăng; quá nhiều abstraction làm code khó theo dõi. Đôi khi code lặp hai lần rõ ràng hơn một framework nội bộ được tạo quá sớm.

## Đánh giá bằng kết quả thay vì cảm giác

Quan sát thời gian review, số file phải sửa cho một thay đổi, lỗi hồi quy và khả năng test độc lập. Code đẹp là tín hiệu phụ; khả năng thay đổi an toàn mới là kết quả chính.

## Giá trị đối với năng lực nghề nghiệp

Refactoring rèn khả năng đọc ý định, quản lý rủi ro và cải thiện hệ thống đang chạy — những kỹ năng phân biệt người biết viết code với kỹ sư làm phần mềm bền vững.

## Câu hỏi tự kiểm tra trước khi chuyển chủ đề

Bạn có thể giải thích Refactoring là gì bằng ngôn ngữ của mình, nêu một trường hợp nên dùng, một trường hợp không nên dùng và chỉ ra cách đo kết quả hay chưa? Nếu chưa, hãy quay lại ví dụ nhỏ trong bài, thay đổi một ràng buộc rồi quan sát điều gì buộc giải pháp phải thay đổi. Đây là cách biến kiến thức đọc được thành khả năng ra quyết định.

## Góc nhìn dành cho developer Việt Nam

Với developer đang làm việc trong các đội sản phẩm tại Việt Nam, hãy dùng nguyên tắc như câu hỏi để review chứ đừng biến chúng thành luật cứng. Mục tiêu là giúp đồng đội đọc nhanh hơn, sửa an toàn hơn và trao đổi chính xác hơn về ý định của code.

## Đọc tiếp trên Wavi Books

Nếu bạn muốn học chủ đề này theo một lộ trình có cấu trúc, có thể xem Clean Code, 2nd Edition bản tiếng Việt tại [Wavi Books](/sach/clean-code-robert-c-martin-2026). Sách liên quan được đặt sau phần kiến thức để bạn có thể đánh giá nội dung trước khi chọn mua.