Sen o jakości

Wydaje się być oczywiste, że każdy zespół chciałby pracować z kodem który można

  • Łatwo przeczytać
  • Łatwo zrozumieć
  • Łatwo modyfikować
  • Łatwo rozszerzać o nową funkcjonalność
  • Łatwo (i pewnie szybko) …

To chyba tak samo jak lubimy kiedy wokół nas jest porządek a nie jego brak. Wówczas na przykład w segregatorach to łatwo coś znaleźć, czy też łatwo dodać kolejny dokument do podobnych już istniejących.

To takie powszechne, że (prawie) każdy programista chciałby pracować (tylko i wyłącznie…) nad nowym kodem i absolutnie trzymać się z daleka od kodu legacy… Ileż już razy to już słyszeliśmy…

Rzeczywistość jakości

No i teraz pojawia się pytanie : jak szybko ten nowy kod, napisany przez nas staje się kodem typu legacy, z którym już nikt nie chce pracować, twierdząc że teraz to trzeba by go napisać od nowa, aby był czytelny, testowalny, rozszerzalny bo obecnie już do niczego się nie nadaje…

A może zadajmy sobie to pytanie inaczej

  • Jak szybko mój własny kod staje się kodem legacy i sam wstydzę się, że to ja go napisałem / am.
  • Jak szybko kod moich kolegów / koleżanek staje się taki, którego już nie lubię i postrzegam go jako źródło samych problemów (bo to inny design niż ja bym zastosował/a itp…)

Moje doświadczenie pokazuje, że kod napisany przez innych staje się tym gorszym, niezbyt lubianym dużo szybciej niż mój “własny kod” (o ile można mówić o “moim kodzie”). A w związku z tym, że prawie zawsze pracujemy w zespole, pozostaje cały czas szukać odpowiedzi na pytanie, czym się ten “czysty kod” rozumiany przez cały zespół. Jak taki kod utworzyć, a może jak obecny kod zmieniać tak aby cały zespół co najmniej go akceptował i podążał za wspólnymi ustaleniami dotyczącymi stylu kodowania oraz architektury.

Jakość na zawsze kiedy będzie obecna od początku?

Trzy lata temu zostałem liderem zespołu który powstawał od początku. Byłem więc pierwszą osobą w tym zespole tak więc i kod który pisaliśmy powstawał od początku. To chyba marzenie każdego programisty… Wydawało się, że ten kod będzie wspaniały i każdy z niego będzie zadowolony pod kątem jakości. Wiedzieliśmy, że wszystko zależy teraz od nas.

Stosowaliśmy dobre praktyki takie jak przeglądy kodu, i byliśmy przekonani, że kod który tworzymy jest czytelny, rozszerzalny, testowalny itd. Jakim zaskoczeniem okazało się więc, żę już po 6-9 miesiącach od początku powstania naszego projektu znaleźliśmy się w sytuacji, gdzie każdy z nas narzekał na kod napisany przez innych i równocześnie potrafił udowodnić że to właśnie jego / jej pomysł na design jest tym najwłaściwszym.

Refaktoryzacja na pomoc

To był moment w którym zaczęliśmy w zespole eksperymentować z refaktoryzacją. Wszyscy wiedzieliśmy że “refaktoryzacja to zmiana struktury kodu bez zmiany jego zachowania”. Z drugiej strony uważam, że nie do końca wiedzieliśmy jak tą refaktoryzację wprowadzić do naszego zespołu tak na stałe. Często refaktoryzacja jest rozumiana jako napisanie kodu od nowa (w lepszej formie) – ale przecież nie o to chodziło. Prawdziwa refaktoryzacja polega na ciągłym ulepszaniu jakości kodu poprzez małe, ale bardzo często i systematycznie wykonywane zmiany.

Na początek postanowiłem “odgrzebać” jedno ze szkoleń które stworzyłem kilka lat wcześniej – “Efektywną Refaktoryzację”.  Plan zakładał przeprowadzenie tego szkolenia dla mojego zespołu z kilku 1.5 – 2 godzinnych kawałkach i pokazanie, że refaktoryzacja w małych krokach jest możliwa, prosta i ciekawa. A następnie – jeżeli plan się powiedzie – zaprezentowanie szkolenia dla osób z innych zespołów.

Przed pierwszą sesją „Efektywnej Refaktoryzacji” dla mojego zespołu zrobiłem eksperyment. Wyszukałem kawałek kodu który wzbudzał duże kontrowersje (swoją złożonością?) i przygotowałem plan kilkunastu małych kroków aby go zmienić na bardziej czytelny. Następnie zaprezentowałem tą refaktoryzację w wersji “na żywo” aby pokazać co możemy osiągnąć podczas takich spotkań refaktoryzacyjnych.

Powyższe doświadczenie było bardzo ważnym punktem dla całego zespołu, gdyż zapoczątkowało dyskusję jakiego kodu chcemy, czym się ma charakteryzować taki kod. Zaczęliśmy pracować nad budowaniem wspólnego rozumienia jakości takiego kodu, aby go tworzyć według naszych wspólnych ustaleń.  Dodatkowo zobaczyliśmy że zmienianie kodu w mały krokach z równoczesną dyskusją o tym jest możliwe i jest bardzo ciekawym doświadczeniem budującym ducha zespołu.

Refaktoryzacja staje się nawykiem

Kiedy praktykowaliśmy refaktoryzację przerabiając moje szkolenie, postanowiliśmy, że każdy z nas znajdzie przykłady w kodzie, które nam (im) się nie podobają i umieszczą je w dokumencie “okazje do refaktoryzacji”. Następnie autor każdego wpisu przygotuje propozycję refaktoryzacji, ustawi spotkanie oraz przeprowadzi tą refaktoryzację “na żywo” zmieniając kod wg swojej propozycji.

Każde takie spotkanie było połączone z dyskusją na temat kierunku zmian naszego designu, naszych wzorców implementacji. Czasem spotkanie kończyło się zaakceptowaniem zmiany zaproponowanej przez autora danej refaktoryzacji, a czasem propozycja wywoływała burzliwą dyskusję. Wtedy taka dyskusja kończyła się tzw. “trzecim (najlepszym wypracowanym) rozwiązaniem” – będącym efektem zaangażowania wszystkich (Stephen Covey – 7 Nawyków Skutecznego Działania : Synergia).

Przeglądy kodu nie zastąpią ciągłej refaktoryzacji

Aby wyszukać miejsca do zmiany, możemy także używać różnych narzędzi do analizy kodu. Nasze doświadczenie pokazuje jednak, że takowe narzędzia potrafią znaleźć oczywiste błędy, duplikacje kodu, ale ostatecznie wymagana jest zawsze wspólna pracy zespołu, polegająca na spotkaniach i dyskusjach. Oczywiście dyskusja “na żywo”, nie poprzez komentarze w Gitlab-ie czy Crubicle-u. Komentarze w tych narzędziach dotyczą prostych zmian, poprawek ale rzadko większych idei.

Ostatnim punktem o jakim chciałbym napisać jest zaufanie oraz otwartość. Podczas naszych pierwszych sesji refaktoryzacyjnych każdy uczestnik – kiedy to właśnie “jego / jej kod” był modyfikowany – zmagał się z postawą defensywną polegającą na obronie swojego wczesniejszego pomysłu na architekturę. Z biegiem czasu zaczęlismy zauważać, że tak naprawdę nikt z zespołu nas nie atakuje, lecz każdy chce przede wszystkim zrozumieć istniejące rozwiązanie i zaproponować swoje ulepszenia aby było ono bardziej czytelne. Nikt natomiast nie miał nigdy intencji udowadniania, że coś jest źle zaprojektowane bądź napisane nieczytelnie, gdy jest to bardzo względne.

Podsumowując, uważam, że nie jest możliwe posiadanie kodu wysokiej jakości bez ciągłej pracy nad jego zmianą. Refaktoryzacja to kluczowa część procesu developmentu. Kiedy się nią zajmujemy to “stajemy się częścią rozwiązania, a nie częścią problemu” (Stephen Covey – 7 Nawyków Skutecznego Działania : Synergia).

Spread the word. Share this post!

Leave a comment