Mặc định hãy chọn refactor. Một cuộc rewrite chỉ chính đáng khi hệ thống hiện tại không còn khả năng tiến hóa để đáp ứng yêu cầu ở một chi phí chấp nhận được, và bạn vẫn tiếp tục mang lại giá trị trong lúc làm. Phần lớn cái cảm giác "chúng ta cần rewrite" thực ra là một vấn đề tech debt không được quản lý mà refactor từng bước có thể giải quyết với rủi ro thấp hơn nhiều.
| Tín hiệu | Nghiêng về refactor | Nghiêng về rewrite |
|---|---|---|
| Kiến trúc phù hợp yêu cầu | Có | Không |
| Độ phủ test/spec | Thấp hoặc cao | Đủ cao để kiểm chứng tương đương |
| Có thể ship từng phần | Có | Khó, big-bang |
| Đội hiểu code | Có | Không, và tác giả gốc đã rời đi |
Lựa chọn refactor-vs-rewrite là một trong những quyết định có đòn bẩy cao nhất mà một Tech Lead đưa ra. Sai về phía rewrite, bạn có thể đóng băng delivery cả năm trời mà vẫn thất bại; sai về phía refactor, bạn rỉ máu tốc độ một cách chậm rãi. Đóng khung nó như một quyết định về chi phí và rủi ro, chứ không phải về khẩu vị, mới là điều tách phán đoán senior ra khỏi sở thích.