clean code

Czysty, czytelny, zwinny soft

Czysty kod jest ważny!

Wie o tym każdy, kto spędził w jednym projekcie więcej niż dwa lata. Jeżeli kod jest czysty – czyli czytelny, to da się go zmienić w sensownym czasie a aplikacja bez trudu nadąży za zmieniającym się rynkiem. Wygląda i zachowuje się po prostu dobrze! Co najmniej dobrze. Czy podbija rynek jak błyskawica zależy od innych czynników. Jadnak czysty kod jest warunkiem koniecznym.

Jak rozpoznać czysty kod?

“Boże, jakie to brzydkie! Czy ja to naprawdę napisałem? Co to w ogóle robi?!”

Jest kilka sposobów sprawdzania czy kod jest czysty:

  1. Można sprawdzić aplikacją np. testability explorer  lub sonara.
  2. Jest też mnóstwo mądrych wytycznych. Moje ulubione to wytyczne Misko Havery – Code Reviewers Guide . Podstawą są też wytyczne zebrane w słynnej książce Uncle Boba Clean Code .
  3. To są świetne sposoby,  ale nie wystarczą. Nic nie zastąpi najważniejszej wytycznej: naszego rozumu. To ludzie będą zmieniać ten kod, więc to ludzie muszą go zrozumieć. Jeśli tylko chcecie napiszę wam kawałek kodu, który przejdzie wszystkie testy, spełni wszystkie warunki a i tak go nie zrozumiecie. Sprawdzanie czytelności przez ludzi jest mniej wygodne, ale tylko ono odpowiada na pytanie czy kod jest czytelny i łatwy do zmiany.

clean code

Czysty kod jak sumienie.

Sam wiesz, czy jest czyste. Ale nie zawsze się przyznasz.

Z drugiej strony czytanie kodu jest może czasem mniej wygodne … ale dość łatwe. Doświadczony programista najczęściej w głębi duszy wie, czy to co napisał jest dobre czy słabe. Czasem przyznajemy się nawet w komentarzach. Wiemy też, kiedy przesadzamy z dopieszczaniem kodu. I najczęściej się nie mylimy.  Ostateczny osąd powinien wydać jednak ktoś inny niż autor kodu. Może to być kolega z zespołu, który siedzie obok w parze lub ktoś, komu przypadło code review.  

Odwagi!

Negatywny feedback

A co jeśli tak nie jest i trzeba powiedzieć, że coś jest do poprawki? Zgroza.Trudno mówić takie słowa!

Dawanie negatywnego feedbacku jest trudne. Wymaga odwagi. Robimy to tylko wtedy jeśli mamy odpowiednią motywację i poczucie bezpieczeństwa. Dwa warunki konieczne.

Czystość kodu

Pokaż mi swój pokój koderów a powiem ci jaki masz kod!

Motywacją jest chęć dostarczenia Product Owner’owi wartościowego produktu i zadbania o klientów, których zespół zna i lubi. A poczucie bezpieczeństwa pojawia się w dobrze zgranym zespole.

Dlatego czystość kodu można poznać też po zachowaniu zespołu:

  • jest głośno, w ciągu dnia słychać dyskusje na temat polityki przeplatane z dyskusjami na temat czystego kodu i jak najlepiej zaimplementować daną funkcjonalność,
  • często słychać wybuchy śmiechu,
  • część ludzi usilnie próbuje odciąć się od dźwięku za pomocą słuchawek,
  • i tak ktoś im przeszkadza co jakiś czas pytając jak coś działa, jak nazywa się metoda która coś robi,
  • w dyskusjach biorą udział ludzie związani z biznesem, z testowaniem i każdą możliwą branżą, która jest ważna dla produktu, który tworzą,
  • nie widać napięcia czy stresu – no chyba, że wywołanego ciekawą dyskusją.

Można to poznać nawet po tym jak wygląda pokój w którym jest zespół:

  • pierwszy rzuca się oczy ogromny monitor z wyświetlonym “continus integration”,
  • ściany są wypełnione, są tam wykresy, diagramy i mnóstwo śmiesznych, mądrych lub słodkich rzeczy w zależności od preferencji zespołu,
  • często widać kilka tablic suchościeralnych z wynikami burzliwych dyskusji lub burzy mózgów,
  • na biurkach są książki tematyczne i przeróżne gadżety.

Generalnie widać że mieszka tu wesoła gromada, która lubi swoją pracę,

Problem życzliwego pasażera

“Popatrz na nich, nic nie dostarczą”

Trudno uwierzyć, że właśnie takie zespoły są wydajne. Takie zachowanie kojarzy nam się z lenistwem. Dlatego naprawdę dobre zespoły często są niszczone przez mało doświadczonych kierowników, którzy widząc taką luźną atmosferę zaczynają się wtrącać w to jak zespół wykonuje swoją pracę. A wiemy przecież od Dana Pinka ( o czym pisałam już tutaj), że autonomia jest warunkiem absolutnie koniecznym do wytworzenia wydajnego środowiska pracy.

Co gorsza niby to wiemy, niby poczytaliśmy u klasyków coachingu ale stare korpo-przyzwyczajenia biorą górę. Ja sama biję się w piersi. Na jednym z pierwszych szkoleń z czystego kodu, obserwując taki zespół zagadałam do swojej co-trenerki. “Popatrz na nich, nic nie dostarczą”.

Po czym zaczęłam zaglądać im przez ramię i próbować coś podpowiadać, zespół jednak twierdził, że są na dobrej drodze i zagadywał mnie na zupełnie nie związane ze szkoleniem tematy. Ostatecznie wymieniliśmy się informacjami na temat ulubionych gier (Herosi!). Gdy czas minął z ciężkim sercem poprosiłam ich o prezentację wyników pracy. Zespół ten jako jedyny ukończył zadania, które dla nich przygotowałam. Ich rozwiązania były zgrabne, czytelne i nie przesadzone.

Wierzcie mi więc, wiem jak trudno jest zostawić taki zespół w spokoju. Wiem też, że warto!

Agent do zadań specjalnych. Pierwszy w Polsce Trener Professional Scrum Developer oraz pierwsza kobieta na świecie z takimi kompetencjami!