W pierwszej części artykułu przyjrzeliśmy się, czy refaktoring jest dla ciebie dobry, co oferuje i jakie są jego konsekwencje. Kontynuujmy więc naszą dyskusję.

Co możesz zrobić, aby uniknąć refaktoringu w przyszłości, lub "Aby coś było dobre, zrób to dobrze"

Menedżerowie często pytają, czy nie można by od razu stworzyć bezbłędnego systemu. Oczywiście, że można, ale zajmie to znacznie więcej czasu. Od lat zajmuję się tworzeniem oprogramowania i w tym czasie zauważyłem, że w większości przypadków rozwój postepuje w sposób ewolucyjny, a jeśli spojrzeć na historię rozwoju systemu operacyjnego od jednego z wiodących producentów, można zauważyć, że tylko co drugi produkt odnosi sukcesy.

Tak czy inaczej, nie można uniknąć błędów, ale można wpłynąć na ich liczbę, podejmując określone działania, takie jak:

• Użycie testów automatyzowanych i jednostkowych
• Wdrożenie BDD
• Zmniejszenie ilości funkcji, wprowadzanie i publikowanie modyfikacji o mniejszych rozmiarach, a tym samym upraszczanie systemu
• Wykonywanie refaktoringu :) o mniejszym rozmiarze, na bieżąco, jak codzienne sprzątanie
• Wymaganie od zespołu odpowiedzialności za opracowywany system
• Zapewnienie dostępu do zmienionej/nowej funkcji ograniczonej liczbie osób, a nie wszystkim naraz, co pozwoli wyjawić problemy znacznie wcześniej
• Użycie ujednoliconych metod architektonicznych, w celu zmniejszenia różnorodności rozwiązań technicznych
• Wprowadzenie i dostosowanie procedury nadzoru technicznego przed utworzeniem nowej funkcji lub wprowadzeniem modyfikacji, przeprowadzenie przeglądu architektury i monitorowanie rozwiązań, rejestrowanie wyników i zbieranie zaleceń
• Wprowadzenie metryk complexity i code quality oraz monitorowanie tych wskaźników

Moje osobiste doświadczenie pokazuje, że nie można uniknąć refaktoringu, ale można zmniejszyc "obrażenia" po jego wprowadzeniu poprzez wprowadzenie wyżej wymienionych działań.

Jeśli mimo wszystko musisz przepisać kod, to jaki masz plan? "Ogłoś całą listę zadań"

Po otrzymaniu pozwolenia na refaktoring, powinieneś poprosić zespół o dostarczenie:

• Listy działań, które należy wykonać, oraz listy konkretnych metryk, które należy poprawić
• Propozycji architektury/szkicu, co należy osiągnąć
• Harmonogramu realizacji prac
• Wykazu ryzyk projektu
• Taktyki zarządzania ryzykiem
• Planu na wypadek, gdyby nie mozna było zakończyć refaktoringu; tak, powinien istnieć plan na wypadek, gdy wszystko zawiedzie

Chcę podkreślić, że można wymagać od zespołu, aby przeprowadził refaktoring w taki sposób, by można go było wdrożyć do systemu nawet w niekompletnej formie, bez wpływu na działanie systemu. W takim przypadku inżynierowie podejdą bardziej odpowiedzialnie do projektu.

Kilka innych zaleceń dotyczących refaktoringu:

• Podziel kod na oddzielne warstwy
• Postępuj zgodnie z architekturą
• Staraj się pisać komponenty/systemy w zwarty sposób i spraw, aby były wymienne
• Zmiejsz poziom zależnosci systemów
• Napisz jak najwięcej testów
• Staraj się wiązać systemy zgodnie ze wspólnymi "protokołami/interfejsami".

P.S.
Ten artykuł może wydać się dość banalny, jednak nie raz obserwowałem przypadki, gdy inżynierowie angażowali się w refaktoring, nie przynosząc tym samym żadnej wartości. Nie jestem przeciwny refaktoringu; jestem za tym, aby był on udany. Jeśli release nie powiódł sie ze względu na przeciągnięty w czasie refaktoring, proszenie o następny refaktoring będzie trudne. Lepiej byłoby ukończyć pierwszy mały refaktoring, udowodnić sens tego działania, zdobyć zaufanie klienta, aby następnie znacznie prościej uzyskać pozwolenie na dalsze kroki.

Długa podróż zaczyna się od małego kroku, a modernizacja systemu rozpoczyna się od drobnych zwycięstw za pomocą prostych i zrozumiałych ulepszeń.

Ivan Alyakskin 
Software Consultant