II. NGUYÊN LÝ TRONG REFACTORING
3. KHI NÀO THỰC HIỆN REFACTORING
Khi chúng ta nói về refactoring, chúng ta thường hỏi làm thế nào để lập lịch. Chúng ta nên cấp hai tuần cho mỗi tháng để refactoring?
Có ba gợi ý của Ron Roberts: lần đầu tiên bạn làm điều gì, bạn chỉ làm nó thôi; lần thứ hai bạn làm điều gì tương tự, làm phản ứng lặp lại, nhưng bạn làm lặp lại bất kỳ lúc nào. Lần thứ ba bạn làm việc gì tương tự, bạn refactor.
3.1 Refactor khi thêm chức năng
Thời điểm chung nhất để refactor là khi chúng ta muốn thêm chức năng mới vào phần mềm. Lý do đầu tiên thường để refactor ở đây là giúp hiểu chương trình chúng ta cần thay đổi. Đoạn code này có lẽ được viết bởi nhiều người khác hay đôi khi chúng ta viết nó. Bất cứ khi nào bạn phải suy nghĩ để hiểu những gì đoạn code đang làm, bạn tự hỏi mình nếu bạn có thể refactor code để làm cho việc hiểu đó ngay lập tức rõ ràng hơn. Thì sau đó bạn refactor nó. Đây là phần thời gian sắp tới bạn đạt được hầu hết bởi vì bạn có thể hiểu nhiều hơn nếu sáng tỏ đoạn code như đã quen thuộc.
Một động cơ khác để refactor là một thiết kế mà không thể giúp bạn thêm chức năng dễ dàng. Bạn nhìn vào thiết kế và tự nói “Chỉ nếu bạn đã thiết kế theo cách này, thì việc thêm chức năng có thể sẽ dễ dàng”. Trong trường hợp này, không quá lo lắng về sai lầm đã qua – bạn sẽ thực hiện bằng refactoring. Bạn thực hiện điều đó trong chừng mực để cải thiện thời gian sắp tới dễ hơn, nhưng hầu như bạn thực hiện nó bởi vì bạn nhận thấy đó là cách nhanh nhất. Refactoring là qui trình nhanh và trôi chảy. Một khi refactor, thêm chức năng có thể tiến triển nhanh và trôi chảy.
3.2 Refactor khi cần sửa lỗi (bug)
Trong sửa lỗi việc sử dụng refactor đến từ việc làm cho code có khả năng dễ đọc. Khi bạn nhìn vào code cố gắng hiểu nó, bạn refactor để giúp cải thiện sự hiểu biết của mình. Thường bạn tìm ở qui trình hoạt động với đoạn code giúp tìm bug. Một cách để nhìn vào vấn đề này đó là nếu chúng ta làm báo cáo về lỗi, đó là dấu hiệu chúng ta cần refactoring bởi code không rõ đủ cho bạn nhìn ra có bug.
3.3 Refactor khi thực hiện duyệt chương trình
Tác giả nhận thấy refactoring giúp duyệt code người khác. Trước khi bắt đầu dùng refactoring, bạn có thể đọc code, hiểu ở mức độ nào đó và thực hiện đề nghị. Khi bạn có thể đưa ra ý kiến, bạn xem xét hoặc chúng có thể thực hiện được dễ dàng hoặc refactoring. Nếu vậy, tiến hành refactor. Khi bạn thực hiện
vài lần, bạn có thể nhìn rõ ràng hơn những gì đoạn có trông giống như đề nghị thay thế. Kết quả là, bạn có thể đạt đến ý tưởng ở mức 2 đó là bạn không bao giờ nhận ra bạn không refactor.