Refaktoryzacja – ot kolejne popularne słowo…. nie zupełnie. Pisząc software nie zawsze dokładnie wiemy jak on będzie wyglądał i co finalnie będzie robił – tzn. w danej chwili (zdefiniowanym kwancie czasu, żeby brzmieć mądrzej) zawsze wiemy co będzie robił, tylko z dalszej perspektywy mentalnej – tj. po dłuższym okresie może się okazać, że robi coś zupełnie innego niż początkowo zakładaliśmy. Oczywiście nie ma w tym nic złego, przecież wszyscy jesteśmy teraz agile jednak nie wiedząc co finalnie będzie robił kod, nie zawsze dobrze możemy zaprojektować jego architekturę. Nie wszyscy nie potrafią, John Skeet potrafi, ale to nie podlega dyskusji.
Architektura powoli ewoluuje i żeby nie skończyć z kupą gruzu, należy o nią dbać. Tym zajmuje się refaktoryzacja właśnie. Tzn. nie tylko tym ale między innymi. Jeśli nie dbamy o kod, nazewnictwo, strukturę i cały ten bajzel to powoli małymi kroczkami zbliżamy się do katastrowy. Ten proces niestety jest bardzo powolny – niestety ponieważ przez to łatwo go zaniedbać. Wymówki w stylu “poprawię później”, “później to zmienię”, “później wydzielę do osobnej klasy” częściej pozostają w sferze NIGDY niż kiedykolwiek się materializują a ponieważ nic się nie dzieje z tego powodu to nie ma czym się martwić. Do czasu aż uświadomimy sobie, że grzebanie w tym konretnym kodzie to straszne bagno ale wtedy jest już za późno. Dlatego o kod trzeba dbać, trzeba być jak skaut, zawsze zostawiać kod odrobine lepszym niż się go zastało.
W refaktoryzacji bardzo pomagają testy i to takie testy, które dają nam jedyne słuszne pokrycie kodu – 100%. Jeśli mamy 100% pokrycie kodu testami, to (teoretycznie) wiemy w 100% co robi nasz kod. Jeśli zaczniemy zmieniać jego strukturę, dostaniemy informację czy nasz kod działa tak samo jak przed zmianami czy nie. W sytuacji idealnej możemy zmienić całkowicie architekturę przyspieszając np. działanie programu bez jakiejkolwiek widocznej zmiany dla użytkownika. Jednak aby to zrobić musimy mieć 100%-owe testy. Przez 100%-towe testy rozumiem, takie, które dają 100% pokrycia kodu (czyli nie ma jakiejkolwiek niesprawdzonej linii kodu) i dają 100% bezpieczeństwo, że psująca zmiana zostanie wyłapana. Mając takie testy mamy komfort wprowadzania zmian. Możemy całość przerobić na CQRSy czy inne wynalazki i mieć pewność, że nic nie zepsuliśmy.
Jeśli nie mamy takich testów to może się okazać, że przy refaktoryzacji coś przypadkiem zepsuliśmy. Jeśli to będzie się zdarzać często to coraz rzadziej będziemy refaktoryzować. To zaś będzie prowadziło do psucia się kodu. Ot koło zamknięte.
