W życiu każdego projektu jest taki moment, w którym pojawia się kwestia refaktoringu. Specjaliści techniczni chcą, aby w projekcie pojawiło się coś nowego, modnego i interesującego. Biznes wymaga szybkiego uzyskania nowych funkcjonalności. Zespół projektowy twierdzi, że wprowadzanie zmian jest mędzące i potrzebny jest refaktoring. Czy brzmi to znajomo?

Przed wyrażeniem zgody na refaktoring systemu/podsystemu powinno się odpowiedzieć na następujące pytania:

1. Czy jest to naprawdę konieczne?
2. Co da nam refaktoring?
3. Jakie będą konsekwencje?
4. Co należy zrobić, aby w przyszłości nie stosować refactoringu?
5. Jeśli mimo wszystko kod trzeba będzie przepisać, to jak wygląda plan?

Czy jest to naprawdę konieczne?

Przed rozpoczęciem refaktoringu należy dokładnie przeanalizować projekt za pomocą automatycznego narzędzia, na przykład SonarQube, w celu oceny istniejącej podstawy kodu. Wykonać pomiary dotyczące wydajności i zebrać szczegółową informację o miejscach, w których można ją ulepszyć.

Następnie należy ocenić, ile czasu inżynierowie poświęcają na obsługę istniejącego rozwiązania i wdrażanie nowych funkcji. Może się okazać, że istniejący system może nie być odpowiedni do rozszerzenia, a dane dotyczące kosztów pracy można pobrać z JIRA/Redmine/Teamcity/TFS. Warto również sprawdzić, w jaki sposób właściciel produktu wprowadza zmiany i czy historie użytkowników (user story) się nie zmieniają. W tym przypadku będzie potrzebny refaktoring procesu pracy i procedur związanych z obsługą Change Requests.

Co da nam refaktoring, albo jaki jest jego sens?

Decydując się na refaktoring, należy uzgodnić, co zostanie zrobione. Postaraj się uzyskać listę konkretnych "korzyści", które zostaną osiągnięte po przeprowadzeniu refaktoringu. Powinny być one wymierne, na przykład:

• Czas realizacji zamówienia zostanie skrócony o X minut
• Czas na wprowadzenie nowej funkcji zostanie zmiejszony o 2 razy
• Refaktoring umożliwi nam przeprowadzenie testów A/B, co doprowadzi do zwiększenia sprzedaży
• Pomoże w obsłudze większej liczby klientów, a tym samym zdobędzie więcej zamówień

Na danym etapie należy zebrać te korzyści, które będą zrozumiałe dla klienta.

Jakie będą konsekwencje, albo "to nie wina programisty"

Podczas przeprowadzania refaktoringu ważne jest, aby zrozumieć, jakie mogą pojawić się konsekwencje, nie tylko te pozytywne. Czy trzeba będzie przeprowadzić testowanie regresyjne? Czy należy uruchomić testy lokalizacji lub wydajności systemu? Jednym słowem, trzeba ocenić, co dodatkowo będzie wymagało naprawy i co trzeba będzie sprawdzić po przeprowadzeniu refaktoringu.

Aby zminimalizować efekty uboczne, po przeprowadzeniu refaktoringu powinieneś poprosić programistów o przeprowadzenie testów jednostkowych i automatyzowanych, w tym testów integracyjnych, które mogą być postrzegane jako dodatkowa praca, jednak posłużą jako kolejny poziom kontroli i pozostaną w systemie jako dodatkowe ulepszenie dla klienta :)

Aby uniknąć niepotrzebnych nadgodzin w przypadku wyjawienia hot fix, należy także przeprowadzić pełen cykl testów regresyjnych oraz szereg sesji testów eksploracyjnych. Pomoże to w znalezieniu kilku interesujących błedów :)

Na koniec, powinieneś mieć świadomość:

• Co może zostać "zakłócone" w rezultacie refaktoringu
• Jak sprawdzimy stan systemu
• Jakie testy/wyniki zostaną podane jako dowód, że wszystko jest we względnym porządku
• Jakie zalecenia programiści przekażą zespołowi kontroli jakości
• W jaki sposób możemy sprawdzić, że "starzy" użytkownicy w żaden sposób nie ucierpią przez wprowadzenie nowych zmian.

W drugiej części artykułu przyjrzymy się, w jaki sposób możemy zminimalizować korzystanie z refaktoringu w przyszłości i jak można zaplanować przepisanie kodu.

Ivan Alyakskin 
Software Consultant