II. NGUYÊN LÝ TRONG REFACTORING
1. ĐỊNH NGHĨA REFACTORING
Định nghĩa 1: sự thay đổi được thực hiện cấu trúc nội tại phần mềm để dễ hiểu hơn và ít tốn chi phí để cập nhật mà không làm thay đổi ứng xử bên ngoài.
Định nghĩa 2: cấu trúc lại phần mềm áp dụng các bước refactoring mà không làm thay đổi ứng xử bên ngoài.
Như vậy, refactoring có phải làm sạch đoạn chương trình? đúng như vậy, nhưng refactoring còn tiến xa hơn bởi cung cấp kỹ thuật cho việc làm sạch đoạn chương trình hiệu quả hơn và kiểm soát hành vi. Khi dùng refactoring, chú ý đến việc làm sạch code hiệu quả hơn trước đây và tối thiểu bug.
Đầu tiên, mục tiêu refactoring là làm cho chương trình dễ đọc và cập nhật khi thay đổi phần mềm chút ít mà không làm thay đổi ứng xử bên ngoài. Tương phản tốt với tối ưu hiệu năng xử lý. Cũng giống như refactoring, tối ưu hiệu năng xử lý không luôn thay đổi hành vi của các thành phần (Components- cái khác hơn là tốc độ) nghĩa là chỉ thay đổi cấu trúc bên trong. Tuy nhiên mục tiêu chúng khác nhau. Tối ưu vận hành thường làm cho đoạn chương trình khó hiểu hơn, nhưng chúng ta cần phải thực hiện nó để tăng tốc độ chúng ta cần.
Thứ hai chúng ta muốn nhấn mạnh đến refactoring không làm thay đổi ứng xử bên ngoài của phần mềm. Phần mềm sẽ thực thi cùng chức năng như trước. Bất kỳ người dùng nào, kể cả người dùng cuối hay người lập trình không thể nói về những sự thay đổi này.
Đó là quan điểm thứ hai triết lý của Kent Beck về hai cái mũ. Khi dùng refactoring để phát triển phần mềm, chúng ta phân chia thời gian giữa hai hành động phân biệt: thêm chức năng và refactoring. Khi thêm chức năng, chúng ta không nên thay đổi chương trình có sẵn; chúng ta chỉ có thể thêm mới khả năng. Chúng ta có thể đo lường tiến độ bằng cách gia tăng kiểm thử và thực hiện kiểm thử. Khi thực hiện refactor, chúng ta thực hiện nhiệm vụ không thêm chức năng; chúng ta chỉ cấu trúc lại đoạn chương trình. Chúng ta không thêm bất kỳ đoạn kiểm thử (trừ khi chúng tìm thấy tình huống sai phạm sớm hơn); chúng ta chỉ thay đổi đoạn kiểm thử khi chúng ta tuyệt đối cần để ứng phó với sự thay đổi trong giao diện.
Khi phát triển phần mềm, chúng ta nhận thấy chính chúng ta sự hoán đổi chiếc mũ thường xuyên. Chúng ta bắt đầu bằng cách thử thêm mới chức năng, và chúng ta nhận rằng điều này có thể dễ dàng hơn nếu đoạn chương trình được cấu trúc khác biệt. Vì vậy chúng ta hoán đổi những chiếc nón và chốc lát thực hiện refactor. Một khi đoạn chương trình được cấu trúc tốt hơn, chúng ta hoán chiếc nón và thêm chức năng mới. Một khi chúng thực hiện chức năng mới, chúng ta nhận ra đoạn chương trình trở nên khó để hiểu, và vì vậy lại hoán đoạn lại chiếc mũ và thực hiện refactor. Tất cả điều này chỉ mất mười phút nhưng trong suốt thời gian này chúng ta luôn nhận thức những chiếc mũ chúng ta đang mang.