ნაგულისხმევად refactoring. rewrite გამართლებულია მხოლოდ მაშინ, როცა არსებული სისტემა მისაღები ფასით მოთხოვნების დასაკმაყოფილებლად ვერ ვითარდება და მისი კეთებისას ღირებულების მიწოდების გაგრძელება შეგიძლია. "rewrite გვჭირდება"-ს ინსტინქტების უმეტესობა სინამდვილეში არამართული tech-debt პრობლემაა, რომელსაც ინკრემენტული refactoring გაცილებით ნაკლები რისკით ჭრის.
| სიგნალი | მიდრეკილება refactor-ისკენ | მიდრეკილება rewrite-ისკენ |
|---|---|---|
| არქიტექტურა შეესაბამება მოთხოვნებს | დიახ | არა |
| Test/spec coverage | დაბალი ან მაღალი | საკმარისად მაღალი parity-ის შესამოწმებლად |
| შეიძლება ინკრემენტული აშიპვა | დიახ | რთული, big-bang |
| გუნდს ესმის კოდი | დიახ | არა, და ორიგინალი ავტორები წავიდნენ |
refactor-vs-rewrite გადაწყვეტა ერთ-ერთი ყველაზე მაღალბერკეტიანი გადაწყვეტილებაა, რომელსაც Tech Lead იღებს. შეცდი rewrite-ისკენ და მიწოდება ერთი წლით შეიძლება გაიყინო და მაინც ჩავარდე; შეცდი refactor-ისკენ და velocity ნელ-ნელა გადიდდება. მისი ჩამოყალიბება, როგორც ფასისა და რისკის გადაწყვეტილება და არა გემოვნების გადაწყვეტილება, არის ის, რაც senior განსჯას უპირატესობისგან განასხვავებს.