Hầu như bất cứ điều gì có thể được phân tích về chi phí và lợi ích, và tôi nghĩ điều này áp dụng ở đây.
Những lợi ích rõ ràng của tùy chọn đầu tiên là nó giảm thiểu công việc trong thời gian ngắn và giảm thiểu cơ hội phá vỡ một cái gì đó bằng cách viết lại mã làm việc. Chi phí rõ ràng là nó giới thiệu sự không nhất quán vào cơ sở mã. Khi bạn đang thực hiện một số thao tác X, nó đã thực hiện một cách trong một số phần của mã và một cách khác trong một phần khác của mã.
Đối với cách tiếp cận thứ hai, bạn đã lưu ý lợi ích rõ ràng: tính nhất quán. Chi phí rõ ràng là bạn phải uốn cong đầu óc để làm việc theo cách mà bạn có thể đã từ bỏ nhiều năm trước, và mã vẫn không thể đọc được.
Đối với cách tiếp cận thứ ba, chi phí rõ ràng chỉ đơn giản là phải làm nhiều công việc hơn. Một chi phí ít rõ ràng hơn là bạn có thể phá vỡ những thứ đang làm việc. Điều này đặc biệt có khả năng nếu (như thường lệ) mã cũ có các kiểm tra không đầy đủ để đảm bảo rằng nó tiếp tục hoạt động chính xác. Lợi ích rõ ràng là (giả sử bạn thực hiện thành công) bạn có mã mới đẹp, sáng bóng. Cùng với việc sử dụng các cấu trúc ngôn ngữ mới, bạn có cơ hội cấu trúc lại cơ sở mã, nó sẽ luôn luôn cải thiện chính nó, ngay cả khi bạn vẫn sử dụng ngôn ngữ chính xác như khi nó được viết - thêm vào các cấu trúc mới tạo ra công việc dễ dàng hơn, và nó cũng có thể là một chiến thắng lớn.
Một điểm quan trọng khác: ngay bây giờ, có vẻ như mô-đun này đã được bảo trì tối thiểu trong một thời gian dài (mặc dù toàn bộ dự án đang được duy trì). Điều đó có xu hướng chỉ ra rằng nó được viết khá tốt và tương đối không có lỗi - nếu không, nó có thể đã được bảo trì nhiều hơn trong thời gian tạm thời.
Điều đó dẫn đến một câu hỏi khác: nguồn gốc của sự thay đổi mà bạn đang thực hiện là gì? Nếu bạn đang sửa một lỗi nhỏ trong mô-đun mà vẫn đáp ứng tốt các yêu cầu của nó, điều đó có xu hướng cho thấy rằng thời gian và nỗ lực tái cấu trúc toàn bộ mô-đun có thể sẽ bị lãng phí phần lớn - đến lúc ai đó cần phải xử lý một lần nữa, họ có thể ở cùng một vị trí như bạn hiện tại, duy trì mã không đáp ứng mong đợi "hiện đại".
Tuy nhiên, cũng có thể các yêu cầu đó đã thay đổi và bạn đang làm việc với mã để đáp ứng các yêu cầu mới đó. Trong trường hợp này, rất có thể những nỗ lực đầu tiên của bạn sẽ không thực sự đáp ứng các yêu cầu hiện tại. Ngoài ra còn có một cơ hội lớn hơn đáng kể rằng các yêu cầu sẽ trải qua một vài vòng sửa đổi trước khi chúng ổn định trở lại. Điều đó có nghĩa là bạn có nhiều khả năng thực hiện công việc quan trọng trong mô-đun này trong thời gian gần (tương đối) và có nhiều khả năng thực hiện thay đổi trong suốt phần còn lại của mô-đun, không chỉ trong một lĩnh vực bạn biết về quyền hiện nay. Trong trường hợp này, tái cấu trúc toàn bộ mô-đun có nhiều khả năng có lợi ích rõ ràng, ngắn hạn, biện minh cho công việc làm thêm.
Nếu các yêu cầu đã thay đổi, bạn cũng có thể cần xem xét loại thay đổi nào có liên quan và điều gì thúc đẩy sự thay đổi đó. Ví dụ: giả sử bạn đã sửa đổi Git để thay thế việc sử dụng SHA-1 bằng SHA-256. Đây là một thay đổi trong yêu cầu, nhưng phạm vi được xác định rõ ràng và khá hẹp. Khi bạn đã lưu trữ và sử dụng SHA-256 một cách chính xác, bạn sẽ không gặp phải các thay đổi khác ảnh hưởng đến phần còn lại của cơ sở mã.
Theo một hướng khác, ngay cả khi nó bắt đầu nhỏ và rời rạc, một thay đổi đối với giao diện người dùng có xu hướng bóng, do đó, bắt đầu như "thêm một hộp kiểm mới vào màn hình này" kết thúc giống như: "thay đổi giao diện người dùng cố định này để hỗ trợ các mẫu do người dùng xác định, các trường tùy chỉnh, bảng màu tùy chỉnh, v.v. "
Đối với ví dụ trước, có lẽ có ý nghĩa nhất để giảm thiểu các thay đổi và sai sót về mặt nhất quán. Đối với sau này, tái cấu trúc hoàn chỉnh có nhiều khả năng trả hết.