W trakcie programowania często zmieniają się wymagania. To jest niezaprzeczalne i jedyne pewne. Natomiast rozwiązania, które się implementuje mimo zmian powinny wyglądać ładnie. Tak czasem oglądam sobie swój kod i dochodzę do wniosku, że mimo iż najstraszniejszy on nie jest, to rozdzielenie logiki biznesowej, dostępu do danych i prezentacji czasem dałoby radę zrobić lepiej. Czasem klasy są na tyle proste, że unika się wydzielania specjalnego providera, ładującego/zapisującego mniejsze obiekty. Z czasem się one jednak rozrastają i powstaje problem. Kod jednej klasy zawiera funkcjonalności, które go niepotrzebnie obciążają. Refaktoryzacja? Byłaby rozwiązaniem, gdyby nie brak testów jednostkowych. Ostatnio jak spróbowałem zrefaktoryzować jeden kawałek, to po 2 dniach przywróciłem wcześniejszą kopię. Z każdej strony natrafiało się na dodatkowe, dotychczas niespotykane problemy.
Refaktoryzować - zgodnie z książkami - trzeba kawałkami. Małymi, powolutku, do przodu. Nie można tego robić zbyt drastycznie. Ewolucja, nie rewolucja.
