Chúng ta giữ code đơn giản mọi lúc. Chúng ta giữ lại sự linh hoạt cần thiết thông qua refactoring. Refactoring là quá trình cải thiện cấu trúc của code trong khi bảo tồn chức năng của nó.

Ngay cả khi bạn đã dành nhiều thời gian để thiết kế trước, điều mà bạn sẽ không làm trong một dự án theo phương pháp XP, các chi tiết về thiết kế của bạn chắc chắn sẽ bị sai ở chỗ này hay chỗ khác. Nếu bạn tập trung vào việc cung cấp giá trị cho doanh nghiệp một cách nhanh chóng, hệ thống của bạn sẽ có nhu cầu phát triển hơn nữa. Refactoring là cách giúp bạn không bị ảnh hưởng xấu bởi những thay đổi phải thực hiện. Bạn đã bao giờ cần một cách làm mới để làm một cái gì đó trong code, thực hiện nó và sau đó ngừng cập nhật tất cả case sử dụng hiện có của cách làm cũ? Có lẽ bạn không, nhưng chúng tôi có gặp, và chúng tôi có thể nói rằng việc này dẫn đến code trở nên khó hiểu, khó cập nhật và chứa sự trùng lặp. Thay vì làm thế, nếu thiết kế cần phải thay đổi, mà chắc chắn sẽ phải thay đổi, thì hãy thay đổi nó. Hãy đưa vào những khả năng mới (new capability) mà bạn cần; di chuyển chức năng đến class phù hợp; hãy tạo ra helper class mới để được call đến. Sau đó hợp lý hóa toàn bộ hệ thống bằng cách sử dụng khả năng mới này ở mọi chỗ khác có thể.

Refactoring là một quy trình chính thức (nhưng không khó) cho phép bạn thay đổi code mà không phá vỡ nó. Mỗi bước refactoring đều có thể đảo ngược, để bạn có thể thử mọi thứ và nếu bạn không thích kết quả, bạn có thể đặt chúng trở lại. Điều này cho phép bạn có một thái độ tò mò, thử nghiệm, học hỏi về code của bạn.

Thông qua refactoring và tập trung vào thiết kế đơn giản, chúng ta có thể xây dựng một hệ thống tăng dần, tập trung vào giá trị doanh nghiệp, mà không bị buộc phải ra một quyết định từ sớm mà sau đó hóa ra là quyết định sai. Chúng ta biết rằng các quyết định ban đầu của mình cần được cập nhật và hãy làm điều đó thông qua refactoring.

Một điều nữa: một lý do khiến mọi người không thay đổi code hiện tại là vì họ sợ họ sẽ phá vỡ nó. Nhưng bạn có tất cả những bài unit test chạy ở mức 100 phần trăm khi bạn bắt đầu. Khi bạn hoàn thành với một chút refactoring, hãy chạy lại chúng. Nếu kết quả là fail, hãy xem xét lý do vì sao. Rất có thể, bạn đã phá vỡ thứ gì đó, mặc dù đôi khi bạn sẽ thấy rằng bài test cần thay đổi để phù hợp với việc refactoring. Các bài test là mạng lưới an toàn của bạn, bảo vệ bạn khỏi phá vỡ hệ thống trong quá trình phát triển nhanh.

Refactoring đề cập đến việc thay đổi cấu trúc nhưng không thay đổi hành vi của code. Tôi sẽ cho bạn một ví dụ. Giả sử một lập trình viên có hai method, mỗi method chứa ba câu lệnh giống nhau. Ba câu lệnh chung này có thể được trích xuất từ ​​cả hai method và đưa vào một method mới được gọi từ cả hai vị trí cũ. Việc refactoring này có một chút cải thiện khả năng đọc và khả năng duy trì của chương trình vì rõ ràng là một số code được sử dụng lại và code trùng lặp đã được chuyển đến một nơi duy nhất. Cấu trúc của code đã bị thay đổi trong khi hành vi của nó thì không. Refactoring không chỉ quan trọng đối với sự thành công của TDD (Test-Driven Development), mà còn giúp ngăn ngừa sự thối code (code decay). Thối code là hội chứng điển hình trong đó một sản phẩm được phát hành, code của nó được phép phân rã trong một vài năm, và sau đó cần phải viết lại toàn bộ. Bằng cách liên tục refactoring và sửa chữa các vấn đề nhỏ trước khi chúng trở thành vấn đề lớn, chúng ta có thể giữ cho các ứng dụng của mình không bị hỏng.

Ứng dụng sẽ cần bảo trì; refactoring là cách làm bảo trì từng ít một tại một thời điểm mà khi làm như vậy là chi phí rẻ. Hầu hết những người quản lý hoặc product owner mà tôi đã gặp, những người đã tuyên bố “các anh không được phép làm refactoring” chỉ vì các đội dự án đã lạm dụng refactoring trong quá khứ. Một ví dụ điển hình là một team dành hẳn ba ngày cuối cùng của mỗi sprint để refactoring. Một nhóm khác nói với product owner của mình là, “Không, chúng ta không thể thực hiện tính năng quan trọng đó trong sprint này vì chúng ta cần phải refactoring những gì chúng ta đã viết trong sprint vừa qua.” Nếu cả team cần ba ngày để refactoring mỗi sprint, thì đó là dấu hiệu của những vấn đề khác nhau. Nếu nhóm đã lên kế hoạch refactoring quá nhiều đến nỗi họ buộc phải từ chối phát triển các tính năng mà product owner muốn có thì trường hợp này bản thân công việc refactoring phải được gộp vào trong Product backlog.

Hãy bắt đầu với một “refactoring backlog” gồm tất cả những thứ bạn muốn dọn dẹp trong code. Nếu team là colocated, chỉ cần viết nó lên một tờ giấy lớn treo ở đâu đó. Nếu team là phân tán, hãy sử dụng tool phần mềm có chức năng tương đương. Mục tiêu là sửa chữa tất cả các vấn đề và sau đó xóa hẳn danh sách refactoring backlog đó sau khi đã done.

Một vài gợi ý về thực hành refactoring

• Hãy tìm hiểu các khả năng refactoring được thực hiện tự động bởi môi trường phát triển tích hợp (IDE) của bạn.
• Khi xác định được cơ hội refactoring, yêu cầu các thành viên trong team viết nó vào thẻ (index card). Treo các thẻ trong một khu vực nhỏ, phân định trên một bức tường trong phòng làm việc của nhóm.
• Vào cuối phiên lập trình kéo dài hai giờ tiếp theo của bạn, hãy dành 20 hoặc 30 phút để dọn dẹp thứ gì đó “có mùi” mà bạn nhận ra khi bạn nhìn vào code hiện có.
• Trong phiên retrospective tiếp theo của bạn, hãy tạo điều kiện để thảo luận về refactoring với các thành viên của bạn, bao gồm cả product owner. Ở ngưỡng nào thì công việc refactoring nên chuyển từ quyết định cá nhân sang quyết định của cả nhóm? Rõ ràng, tôi có thể đổi tên một biến có tên được đặt không đúng chuẩn mà không cần thảo luận nhóm. Điều gì sẽ xảy ra nếu các developer gặp phải một sự thay đổi tốn đến hai ngày công: họ có thể dành 2 ngày làm refactoring hay không? Hoặc trước tiên product owner cần phải phê duyệt công việc refactoring?
• Chúng ta có thể thực hiện các cải tiến rất nhỏ, tăng dần cho code. Tại mỗi thời điểm, phiên bản mới nhất tốt hơn phiên bản trước
• Các unit test hoạt động như một mạng lưới an toàn. Chúng ta không bao giờ đi quá xa mà không có sự đảm bảo chạy thành công các unit test đã được viết
• Có thể một số phép refactoring sẽ ảnh hưởng đến hiệu suất hoạt động của ứng dụng, nhưng chúng thường sẽ mở ra những khả năng cải tiến mạnh mẽ
• Làm cho refactoring (bao gồm cả test!) là một phần của thực hành lập trình thông thường của bạn. Hãy cảnh giác với “code smell”, và tìm hiểu các phép refactoring có thể giải quyết chúng. Bạn sẽ được đền đáp bằng sự đơn giản và linh hoạt mà hệ thống sẽ có

Theo Mike Cohn

Succeeding with Agile

Theo Ron Jeffries

Extreme Programming Installed