Refactor code cũng cần phải có chiến lược
April 9, 2025Hiển nhiên code của chúng ta luôn luôn có những thứ có thể “refactor” cho đẹp hơn, tốt hơn… Tuy nhiên trước khi làm điều ấy, hãy cân nhắc cẩn thận những điều sau đây để tránh lãng phí thời gian cũng như công sức của bạn (và các đồng nghiệp của bạn):
Chúng ta thường có xu hướng chê bai những đoạn code hay hệ thống cũ, và cho rằng mình có thể viết tốt hơn. Chúng ta có thật sự hiểu chúng trước khi quyết định refactor chưa?
Hãy xem xét kĩ nó trước đã, và cả những unit-test đi kèm để có thể biết được lý do tồn tại, cũng như những điểm mạnh/điểm yếu của nó. Khi hiểu rồi, bạn mới có thể refactor nó tốt hơn và tránh gây ra những lỗi không mong muốn.
Lập trình viên cũng thường có xu hướng muốn “đập đi làm lại” mọi thứ một cách rất tự tin. Tuy nhiên, điều này cần phải hết sức cẩn thận và nên tránh. Là con người thì chắc chắn sẽ có sai sót. Những đoạn code cũ tuy nhìn có thể hơi “xấu”, nhưng nó đã được test cẩn thận hàng năm trời, và cũng có thể đã được nhiều lần tối ưu hoặc sửa lỗi ngay trên những đoạn code đó. Việc viết lại mới hoàn toàn, bạn có thể sẽ gây ra những lỗi tiềm ẩn (có thể đã được fix trước đó), và sẽ tốn khá nhiều thời gian để test lại toàn bộ chúng.
Chia việc refactor code thành nhiều lần nhỏ nhưng đều đặn, sẽ tốt hơn là refactor lớn một cách đột ngột. Việc chia nhỏ như vậy sẽ giúp giảm thiểu công sức refactor của chúng ta, giảm thiểu số lượng bug có thể gây ra, và công sức test lại chúng cũng nhỏ đi rất nhiều. Hãy tưởng tượng một lần thay đổi nhỏ, với 2 con bug được phát hiện, sẽ “dễ chịu” hơn nhiều so với một lần thay đổi lớn với vài chục con bug.
Bạn cần đảm bảo rằng unit-test hiện tại phải luôn pass, và cần viết thêm unit-test để cover những thay đổi mới. Hãy cẩn trọng và cân nhắc trước khi xóa những unit-test cũ vì có thể chúng vẫn còn có ích sau này.
Đừng refactor code chỉ vì nhận định chủ quan hay cái tôi của bạn. Nếu code hiện tại không có lỗi gì, sao lại phải fix nó chứ? Phải chăng bạn muốn viết lại chỉ vì nhìn nó không đúng “style” của bạn? Lý do này không hợp lý chút nào. Và cho rằng bạn có thể làm tốt hơn người trước cũng không phải là một lý do hợp lý.
“Công nghệ mới” cũng không phải là lý do đủ hợp lý để thay đổi. Chúng ta thường cho rằng code hiện tại khá lỗi thời, và thư viện mới, framework mới sẽ xử lý công việc tốt hơn rất nhiều. Tuy nhiên, bạn cần chắc chắn rằng chúng đã được chứng minh (thống kê tin cậy) về khả năng cải thiện hiệu suất cũng như chất lượng của các library/framework… Không thì tốt nhất cứ để nguyên hệ thống như vậy.
Việc sử dụng library/framework mới cũng cần cân nhắc về độ ổn định và phổ biến của chúng trong cộng đồng. Ai là người maintain chúng (cá nhân hay tổ chức), họ có khả năng drop dự án bất thình lình không?
