Aby wyrazić swój pogląd:
Małe, przyrostowe zmiany, które pozostawiają kod w lepszym stanie niż został znaleziony
Zdecydowanie tak: zmiany „kosmetyczne”, które nie są bezpośrednio związane z funkcjami (tj. Nie są rozliczane jako żądanie zmiany).
Zdecydowanie nie: przepisywanie dużych fragmentów w oczywisty sposób narusza część „małych, przyrostowych”. Refaktoryzacja jest często używana jako przeciwieństwo przepisywania: zamiast robić to ponownie, ulepsz istniejące.
Zdecydowanie być może: zastępowanie struktur danych i algorytmów jest przypadkiem granicznym. Decydującą różnicą w tym przypadku IMO są małe kroki: bądź gotowy do dostarczenia, bądź gotowy do pracy nad inną sprawą.
Przykład: Wyobraź sobie, że masz moduł Report Randomizer, który jest spowolniony przez użycie wektora. Zaprofilowałeś, że wstawianie wektorów jest wąskim gardłem, ale niestety moduł opiera się na pamięci ciągłej w wielu miejscach, więc podczas korzystania z listy rzeczy po cichu się psują.
Przepisanie oznaczałoby wyrzucenie modułu z budynku na lepszy i szybszy od zera, po prostu wybranie kilku elementów ze starego. Lub napisać nowy rdzeń, a następnie dopasować go do istniejącego okna dialogowego.
Refaktoryzacja oznaczałaby podjęcie małych kroków w celu usunięcia arytmetyki wskaźnika, tak aby przełącznik. Może nawet utworzysz funkcję narzędzia zawijającą arytmetykę wskaźnika, zastępując bezpośrednią manipulację wskaźnikiem wywołaniami tej funkcji, a następnie przełącz się na iterator, aby kompilator narzekał na miejsca, w których arytmetyka wskaźnika jest nadal używana, a następnie przełącz się na a list, a następnie usuń funkcja ultility.
Pomysł polega na tym, że kod sam się pogarsza. Podczas naprawiania błędów i dodawania funkcji jakość spada małymi krokami - znaczenie zmiennej nieznacznie się zmienia, funkcja otrzymuje dodatkowy parametr, który przerywa izolację, pętla staje się nieco skomplikowana itp. Żaden z nich nie jest prawdziwym błędem, możesz Nie mów liczby linii, która sprawia, że pętla jest złożona, ale szkodzi czytelności i konserwacji.
Podobnie, zmiana nazwy zmiennej lub wyodrębnienie funkcji nie są same w sobie namacalnymi ulepszeniami. Ale razem walczą z powolną erozją.
Jak ściana z kamyków, w której codziennie upadamy na ziemię. I codziennie jeden przechodzień podnosi go i odkłada.