fbpx

Sen o jakości

Czy chcesz aby Twój zespół pracował z kodem który można łatwo

  • przeczytać?
  • zrozumieć?
  • modyfikować?
  • rozszerzać o nową funkcjonalność?

Chyba wszyscy lubimy kiedy wokół nas jest porządek. Wówczas na przykład w segregatorach to łatwo coś znaleźć, albo łatwo wstawić nowy dokument w odpowiednie miejce.

Niestety często z powodu bałaganu niejeden programista chce pracować (tylko i wyłącznie…) nad nowym kodem. Bałagan powoduje że trzymamy się z daleka od kodu legacy, sczeghólnie kiedy nie potrafimy skutecznie go refaktoryzować aby zamienić na czysty kod.

Rzeczywistość w pracy nad jakością kodu

No i teraz pojawia się pytanie : jak szybko ten nowy kod (teoretycznie Czysty Kod), napisany przez nas staje się kodem typu legacy? Nagle już nikt nie chce z nim pracować, twierdząc że teraz to trzeba by go napisać od nowa? Bo już nie jest ani czytelny ani testowalny ani rozszerzalny? I teraz to już do niczego ten kod 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 szybko staje się tym gorszym. Jest on dużo mniej lubianym niż mój “własny kod” (o ile można mówić o “moim kodzie”). Kiedy więc ten “czysty kod” rozumiany przez cały zespół jako rzeczywiście czysty? Jak taki kod utworzyć, a może jak obecny kod zmieniać tak aby cały zespół podążał za wspólnymi standardami stylu kodowania oraz architektury?

Jak długo nowy projekt zawiera kod o lepszej jakości?

Dawno tego 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 „czysty kod” będzie wspaniały i każdy z niego będzie zadowolony. Wiedzieliśmy, że wszystko zależy teraz od nas.

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


Pobierz bezpłatne materiały z V/Blogów i dołącz do newlettera

Webinary, Artykuły oraz Kursy Online i Stacjonarne

Wysyłaj do mnie newletter (możesz się wypisać w każdej chwili).

Akceptuję Politykę Prywatności i Regulamin


Refaktoryzacja na pomoc

Natąpił 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 na stałe. Często refaktoryzacja jest rozumiana jako napisanie kodu od nowa (w lepszej formie) . Tymczasem 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 – “Efektyną Refaktoryzację Czystego Kodu”.  Plan zakładał przeprowadzenie tego szkolenia dla mojego zespołu z kilku 1.5 – 2 godzinnych kawałkach. W ten sposób chciałem pokazać, ż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. 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. Zapoczątkowało dyskusję jakiego kodu chcemy, czym się ma charakteryzować Czysty Kod. Zaczęliśmy pracować nad budowaniem wspólnego rozumienia jakości takiego kodu, aby go tworzyć według naszych wspólnych standardów.  Dodatkowo zobaczyliśmy że refaktoryzacja kodu w mały krokach z równoczesną dyskusją jest możliwa. Poprzez to doświadczenie zaczęliśmy budować ducha zespołu.

Sesje refaktoryzacji kodu w zespole

Kiedy uczyliśmy się refaktoryzacji praktykując moje szkolenie, postanowiliśmy, że każdy z nas znajdzie przykłady w kodzie, które nam (im) się nie podobają. Następnie umieścilśmy te przykłady w dokumencie “okazje do refaktoryzacji”. Postanowiliśmy, że autor takiego wpisu przygotuje sesję refaktoryzacji, ustawi spotkanie oraz przeprowadzi tą refaktoryzację “na żywo”.

Każda taka sesja refaktoryzacji była połączona 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ę. Wówczas 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 poprawy jakości kodu na czysty, możemy także używać narzędzi do analizy kodu. Nasze doświadczenie pokazuje, że chociaż takowe narzędzia potrafią znaleźć duplikacje kodu to ostatecznie wymagana jest wspólna pracy zespołu nad rozwiązaniem. 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.

Refaktoryzacja buduje zespół

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ą. Postawa ta polegała 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. Każdy uczestnik chce zrozumieć istniejące rozwiązanie lub 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. Takie rzeczy są bardzo względne.

Podsumowując, uważam, że nie jest możliwe posiadanie kodu wysokiej jakości bez ciągłej pracy nad Czysty Kodem. Refaktoryzacja to kluczowa część procesu developmentu. Kiedy ma miejsce w zespole to “staje się częścią rozwiązania, a nie problemem” (Stephen Covey – 7 Nawyków Skutecznego Działania). Wówczas nie trzeba na nią szukać dodatkowego czasu.

Spread the word. Share this post!