Jakiś czas temu napisałem post dotyczący sesji refaktoryzacji kodu, które zorganizowałem z moim zespole. Przez pewien czas miewały się one bardzo dobrze i cieszyły popularnością. Potem jednak zniknęły… Jak to możliwe skoro wszyscy z nas bardzo je lubili?

Na szczęście temat spotkań dotyczących refaktoryzacji kodu wrócił i zadomowił się na stałe w moim zespole – chociaż w nieco zmienionej formie – tzw. sesjach inspektoryzacji kodu (to nasza nazwa własna). I chociaż te sesje nie odbywają każdego dnia czy w każdym tygodniu, to jednak stały się częścią pracy naszego zespołu.

W tym poście będę chciał opowiedzieć o trzech rzeczach

  • Dlaczego nasze sesje refaktoryzacji kodu zniknęły?
  • Czym są nasze sesje inspektoryzacji kodu?
  • Dlaczego nasze sesje inspektoryzacji kodu na dobre “zadomowiły się” w pracy naszego zespołu?

Myślę, że kluczem i tym co łączy odpowiedź na wszystkie trzy powyższe pytania jest motywacja. Sesje refaktoryzacyjne (wg naszej definicji) wymagały aby prowadzący dane spotkanie był do niego przygotowany, aby przygotował wcześniej plan refaktoryzacji, poszczególne kroki oraz końcowy cel. To powodowało, że kiedy rozpoczynała się dyskusja “dlaczego tak”, “a może inaczej” prowadzący który chciał zaprezentować swój pomysł mógł znaleźć się z defensywie.

W ten oto sposób przeprowadzenie takiego spotkania wymagało dużo pracy i wysiłku. Co więcej – jako że podczas spotkań toczyliśmy dyskusje – trzeba było się przygotować coraz bardziej, coraz lepiej. W ten sposób – jako że perfekcjonizm zabija – coraz trudniej było się zdecydować na ustawienie, przygotowanie i przeprowadzenie takiego spotkania.  

 

 

Powyższe podejście nazywane się pułapką koła perfekcjonizmu. Chcesz być coraz lepszy każdego dnia, tygodnia, aż w końcu nawet boisz się zrobić pierwszy krok w obawie przed porażką. Pamiętam, kiedy jeden z managerów zachęcał swój zespół aby raz z tygodniu poświęcili trochę czasu na eksperymenty, bardzo podkreślając jednak, że powinny one mieć 50S% szans na sukces jak i na porażkę. I tutaj miał 100% racji. Jeżeli Twój eksperyment nie może się zakończyć porażką (albo na najmniej oczekiwany jest jego sukces) nie nie jest eksperymentem. Jedynym oczekiwaniem z każdego eksperymentu powinno być wyciągnięcie wniosków i konkluzji – tak z sukcesu jak i z porażki.

 

 

Tymczasem nasze sesje refaktoryzacyjne miały z pewnością niezapisane oczekiwanie sukcesu. Być może zostało ono przeniesione ze szkoleń z refaktoryzacji które prowadziłem. Bo podczas nich było ciekawie, a refaktoryzacje które prezentowałem (przygotowane i zaplanowane) zawsze kończyły się sukcesem. Wszak było to przygotowane szkolenie więc trudno aby było inaczej.

Po kilkunastu tygodniach braku naszych sesji refaktoryzacyjnych jeden z członków mojego zespołu (dziękuję Jakub!) zaproponował inne podejście. Zasugerował zorganizowanie sesji “inspekcji kodu” z którymi miał do czynienia w swojej poprzedniej pracy. Formuła tego spotkania definiowała poniższe role przypisane do uczestników

  • Reader – odpowiedzialny za czytanie i interpretację działania kodu źródłowego
  • Writer – odpowiedzialny za zapisanie akcji do wykonania
  • Author – odpowiadający na pytania osoby czytającej kod
  • Moderator – odpowiedzialny za przebieg spotkania

Spotkanie przebiegło bardzo sprawnie – pomimo bardzo restrykcyjne formuły (a może właśnie dzięki niej). Ale jak wiadomo – programiści chcą być “agile” i nie lubią za bardzo sztywnych reguł. W związku z tym podczas następnych sesji “inspekcji kodu” zaczęliśmy eksperymentować z w/w formuła spotkania. Eksperymenty te doprowadziły nas do utworzenia nieco luźniejszej reguły poprzez dodanie tego, co nam się podobało podczas sesji refaktoryzacyjnych – poprawiania kodu w czasie rzeczywistym oraz wielu dyskusji.

W ten sposób powstały nasze sesje “inspektoryzacji kodu”. Inspektoryzacja = inspekcja + refaktoryzacja. Sesje te

  • Mogą być prowadzone przez każdego
  • Nie wymagają wcześniejszego przygotowania i znajomości danego kodu
  • Nie mają oczekiwania że zakończymy z lepszym kodem
  • Mają wyraźne oczekiwanie zaangażowania każdego uczestnika w dyskusję i pomysły zmian

Powyższe podejście jest nazywane “anty-perfekcyjnym kołem myślenia”. Jedynym oczekiwaniem było lepsze zrozumienie danego kodu, oraz zidentyfikowanie ewentualnych przyczyn będących przeszkodą w szybkim zrozumieniu i wprowadzenie poprawek zwiększających czytelność i przejrzystość. A wszystko to ma być zawsze wynikiem naszej wspólnej dyskusji, dzięki której wymieniamy się doświadczeniami jak i budujemy wspólne oczekiwania dotyczące jakości naszego kodu.

 

 

Celem więc staje się ciągły postęp, a nie perfekcyjnie ustanowiony cel.

W następnym poscie podzielę się moimi kolejnymi spotrzeżeniami dotyczącymi refaktoryzacji – dlaczego / kiedy ma ona miejsce a kiedy (raczej) nie. Spojrzę na problem z takich perspektyw jak plany biznesu, relacje pomiędzy biznesem z zespołem programistów, zarządzaniem procesem developmentu czy też zarządzanie ludźmi.

 

Leave a comment