Refactoring good practices

Xin chào các bạn! Chắc hẳn chúng ta trong quá trình làm dự án cũng không ít lần thực hiện việc refactor code. Việc này đôi khi là để cho code trông dễ đọc và "pro" hơn, nhưng đôi khi là rất cần thiết để tránh phát sinh lỗi không đáng có. Hôm nay mình xin giới thiệu với các bạn một bài viết trên trang https://blog.inf.ed.ac.uk/sapm/2014/03/14/refactoring-good-practices/, hy vọng sẽ có ích cho các bạn trong quá trình làm việc.

I. Refactor là gì? Refactor là một cách tái cấu trúc lại. Về mặt kỹ thuật, nó là việc viết lại phương thức, thuật toán gọn gàng và dễ hiểu hơn mà vẫn cho kết quả tương đương. Điều quan trọng nhất là, kết quả trước và sau khi refactor phải hoàn toàn giống nhau.

Ý tưởng của refactoring là để cải thiện thiết kế của một ứng dụng đang chạy, do đó thiết kế lại toàn bộ là cách tốt nhất, tuy nhiên chúng ta không nên làm như vậy thường xuyên vì nó tiềm ẩn khá nhiều rủi ro. Việc thay đổi lại toàn bộ code đang chạy đúng trong có vẻ tốt nhưng chúng ta không dám chắc nó hoạt động chính xác. Để tránh mắc phải điều này, chúng ta nên dùng unit test, test lại các tính năng trên các môi trường độc lập nhau.

II. Tại sao phải refactor?

Trước hết, chúng ta nên đặt câu hỏi tại sao phải refactor?

Lý do chủ yếu là:

• Việc cải thiện code làm cho nó dễ hiểu, dễ đọc hơn. Thực tế thì thời gian bạn dành để đọc code lơn hơn thời gian viết code rất nhiều. Bởi vì chúng ta viết 1 lần và thường phải đọc lại khá nhiều lần.
• Đảm bảo rằng code viết ra không bị trùng lặp, như vậy khi có thay đổi, chúng ta chỉ phải sửa ở một hàm thay vì ở nhiều hàm khác nhau, điều đó giúp giảm thời gian bảo trì và hạn chế lỗi xảy ra.
• Đơn giản vì chúng ta muốn có một sản phẩm có chất lượng cao .

Chúng ta thường thực hiện refactor trong các trường hợp sau:

• Trước khi thay đổi code hiện tại (thường do thay đổi yêu cầu)
• Mỗi khi có chức năng mới bổ sung vào hệ thống.
• Trước khi tối ưu hóa lại thiết kế hệ thống.
• Trong quá trình debug hoặc review code.

Việc refactor code thường xuyên bị chỉ trích, vì có khi ta hay cố gắng đoán trước yêu cầu trong tương lai mà không biết những gì ta nghĩ là đúng hay sai. Và mặc dù code thay đổi, ta liệu có chắc chắn được là bỏ ra 1 tiếng refactor có đảm bảo ít nhất 1 tiếng việc sữa chữa bảo trì trong tương lai.

Chúng ta thường ngụy biện rằng việc refactor tốn nhiều thời gian, ảnh hưởng đến tiến độ dự án, tuy nhiên, dữ liệu lịch sử cho thấy rằng phần lớn các ứng dụng liên tục được sửa đổi trong quá trình phát triển. Chúng ta bỏ thời gian refactor code và sẽ còn tiết kiệm được nhiều thời gian hơn thế.

III. Refactor code một cách an toàn

Như đã nói ở trên, việc refactor code tiềm ẩn nhiều rủi ro.Thay đổi một đoạn code đang chạy, dù trông có vẻ đẹp hơn thì cũng chưa chắc đã chạy đúng. Có một người nổi tiếng từng nói "Nếu nó đang chạy đúng, đừng động vào nó", sửa một đoạn code đang chạy đúng rất dễ gây ra lỗi mới. Đây là một số lời khuyên nếu bạn đang có ý định refactor code:

• Làm từng bước một, thay đổi dần dần code cũ.
• Liên tục chạy unit test, sau đó là integration testing và functional testing.
• Sử dụng 1 số tool hỗ trợ refactor trên môi trường develop nếu có.
• Nếu được, refactor code cùng với người đã viết ra nó hoặc những người làm cùng. Điều này giúp chúng ta hiểu rõ ý đồ thuật toán và hạn chễ lỗi.

Khi thực hiện refactor, các thay đổi nhỏ trong code sẽ dẫn đến lỗi lớn. Khi có lỗi xảy ra, chúng ta rất khó xác định nguyên nhân và sửa lỗi, vì vậy luôn luôn sửa từng phần một và có backup code đề phòng trường hợp lỗi.

Công cụ hỗ trợ refactoring luôn đáng tin cậy hơn copy paste code. Trong một thời gian dài, không có quá nhiều công cụ như vậy nhưng ngày nay có rất nhiều các môi trường phát triển cung cấp công cụ refactoring tốt, hỗ trợ viết code ngắn gọn, dễ đọc và tìm ra vấn đề.