Zasada skautów zaprezentowana w książce Wujka Boba (pt. Clean Code), jest parafrazą pożegnania skautów. Przeniesiona na grunt programistyczny, stała się jedną z najbardziej rozpowszechnionych oraz chętnie podawanych zasad w środowisku programistycznym.
Zawsze zostawiaj obóz czystszy, niż go zastałeś.
Czyli w dużym uproszczeniu – usprawniaj kod w miejscu w którym wprowadzasz zmiany.
Brzmi dumnie i też sprawia, że duma rozpiera programistę gdy podczas swojej codziennej pracy udało mu się ją „spełnić”. Tym samym, programista też się „spełnia”, bo nie dość, że realizuje powierzone mu zadania, to na dodatek dba o wspólne dobro zespołu, jakim jest m.in. kod rozwijanej aplikacji. Brzmi to bardzo patetycznie i co niektórych te kilka słów może przyprawiać o odruch wymiotny. Jednak tak właśnie czułem się ja – gdy wraz z nową funkcjonalnością, poprawionym błędem dostarczałem kilka „usprawnień na plus”.
Usprawnienia
Praktycznie cudzysłów w poprzednim akapicie powinien oplatać słowo „kilka”. Bo zdarzało się, że nie było to kilka usprawnień, niezbędnych do wprowadzenia nowej funkcjonalności, ale duży zestaw zmian, które wprowadziłem „przy okazji”. Przy okazji zaciemniając implementację docelowego rozwiązania, zwielokrotniając ilość wprowadzonych zmian. W kilkuletnim kodzie, pamiętającym bagaż różnorodnego doświadczenia programistów – nie trudno o popełnienie błędu. Nie łudźmy się, nie każde oprogramowanie posiada testy automatyczne (na jakimkolwiek poziomie), które wspomagają w wyłapywaniu problemów. Nie zawsze znamy także odziaływanie każdej linijki w kodzie na całość oprogramowania. Często rozwijamy utworzony przez kogoś spory kawałek kodu.
Wiem natomiast, że chęć usprawniania – pomimo szczerych chęci – nie koniecznie usprawnia w ogólnym kontekście jakość projektu. Hmm…
Usprawnianie 100 linijek kodu z 100k linii, kosztem 10 nowych błędów nie brzmi zbyt dobrze.
Jednak, DROBNE usprawnienia realizowane na bieżąco, jako część Continous Refactoring to coś o czym powinniśmy pamiętać realizując swoją codzienną pracę.
Sama idea jest jak najbardziej słuszna. Jednak między jej słusznością, a przegięciem istnieje cienka granica. Należy równoważyć ilość dodatkowych zmian, realizowanych „przy okazji”. Tym bardziej gdy dotyczą one zupełnie innej części aplikacji, niż ta w której faktycznie wprowadzamy zmiany.
Przygotowanie podłoża
Podobnie jest z samym przygotowywaniem się do wprowadzenia nowej funkcjonalności, aby jej realizacja nie opierała się na tworzeniu hacków w kodzie i kolejnych zagnieżdżonych ifów. Warto posprzątać miejsce w którym rozpalamy ognisko, bo po naszym ognisku będzie jeszcze gorzej. Nie myśląc już o kolejnym powrocie w to miejsce.
Gdy potrzebuję przygotować sobie podłoże do wprowadzenia zmian, zachęcam do przetestowania prostego algorytmu:
- Przygotowanie miejsca – uprzątnięcie, przygotowanie się na łatwiejsze wprowadzenie nowej funkcjonalności.
- Przeprowadzenie testów regresji.
- Docelowa implementacja funkcjonalności w oparciu o przygotowane podłoże.
- Testy regresji oraz testy akceptacyjne.
Oczywiście mając na uwadze jeden z poprzednich postów nt. Code Review, po pierwszym oraz trzecim kroku, prosiłbym zespół programistyczny o weryfikację zmian. Tak aby zmniejszyć ilość zmian do przejrzenia podczas jednego Code Review oraz aby w ani pierwszym, ani w drugim przypadku nie zaciemniać kodu. By jasno z niego wynikało co konkretnego chcę zrealizować.
Mówiąc przykładem, jeśli w systemie istnieje możliwość generowania raportu do pliku PDF, a nas czeka implementacja generowania raportu do pliku HTML wykonałbym następujące czynności:
- Przygotowanie kodu do możliwości zmiany sposobu generowania raportu, np. wprowadzając wzorzec strategii.
- Prośba o Code Review oraz przeprowadzenie testów regresji.
- Implementacja generowania raportu do pliku HTML w oparciu o przygotowany interfejs strategii.
- Testy regresji oraz testy akceptacyjne.
Sprowadza się to do zaplanowania i dekompozycji pracy na mniejsze elementy składowe. W tym wypadku na konkretne dwa:
- Przygotowanie podłoża do nanoszenia zmian.
- Naniesienia wymaganej zmiany, aby dostarczyć oczekiwane rozwiązanie.
Podsumowanie
Tak, zasada skautów mówi o sprzątaniu – w kodzie. Naprostowałbym jednak dwa elementy, gdy tak chętnie podnosimy temat i krzyczymy „ej, ale Bob opisując zasadę skautów mówił aby poprawiać takie rzeczy!„:
- Ciągłe usprawnienia – tak! Ale tylko takie które nie zaciemniają docelowej implementacji. Większe zmiany wyodrębniane jako zupełnie osobne zadania. Do tematu samego refactoringu powrócę w odrębnym poście.
- Przygotowanie podłoża – tak! Jednak postępując według zaproponowanego algorytmu. Dekomponując pracę i weryfikując ją mniejszymi porcjami.
EOT
Na zakończenie zostawię jeszcze jeden, fajny cytat z książki Wujka Boba.
Podpisuję się pod nim.
The act of leaving a mess in the code should be as socially unacceptable as littering.
— Robert C. „Uncle Bob” Martin
