Techniczne retro w Twoim projekcie

Tylko nie idź do projektu XYZ

Zawsze przychodzi moment kiedy stykasz się z kodem o którym piszą opowieści a starzy wyjadacze cichym głosem mówią: "Unikaj projektu XYZ, to najgorzej napisany kod w historii firmy."

Miałem tak w każdej pracy, uważaj na projekt o tajemniczej nazwie. Niestety niewiele osób chciało o nim rozmawiać. I weź się rozwijaj...

Można uczyć się na dwa sposoby. Jeden to nauka wśród najlepszych, podglądanie jak oni piszą i tworzenie wzorowego kodu. Poznajemy techniki, dobre metody, dostajemy twarde code review.

Mamy też ogrom możliwości i zadowolenia. Wszyscy chwalą kod, projekt i jesteś dumny z przynależenia do tej "elity".

Z drugiej strony nie jesteś samodzielny. Wiesz tylko o dobrych rzeczach, masz wysoką pewność siebie. Trafiasz sam do nowego projektu i z bagażem doświadczeń zaczynasz tworzyć. Idzie super do pewnego momentu, w którym zaczyna Ci brakować wiedzy jak powstają złe projekty. Rośnie dług techniczny, ponieważ trzeba coś na szybko dostarczyć. Później na to miejsce dobudowujesz nowe warstwy.

Czujesz się coraz bardziej winny i odpowiedzialny za to co się dzieje. Ale nikt Cię nie nauczył jak walczyć z legacy code.

Odwrotna sytuacja, czas zaorać zły kod

To chyba najgorszy moment i żaden młody dev nie powinien trafić do projektu z legacy code. Powinien zacząć od nowego z całym zespołem tak jak wyżej. Tylko jedna ważna różnica. Gdy przychodzi czas na zmianę projektu, nie powinien zaczynać od zera. Lepiej niech trafi do starego i mimo płaczu czerpie korzyści.

Doświadczenie zebrane od zespołu pokaże tutaj najważniejszą z cech programisty. Jak sobie radzi ze złym kodem. Czy będzie potrafił zastosować co się nauczył? Czy zrozumie błędy w architekturze? Czy ogarnie ogrom kodu?

To prawdziwy test i okazja do rozwoju. To moment w którym zadziera się rękawy i bierze się do roboty. Jak prawdziwy rzemieślnik. Z dumą pull request po pull request'ie wysyłając kod do seniorów. Patrzcie i mówcie czy coś jeszcze da się poprawić.

Masz szansę na wykazanie się. Projekt, który do tej pory wszyscy omijali staje się coraz lepszy. Linia po lini coraz łatwiej się pracuje z nim.

Duma nie z tworzenia ale z naprawiania

Przychodzi po jakimś czasie. Z zaangażowaniem opowiadasz jak pozbyłeś się dziwnych struktur lub nieprzemyślanych decyzji.

Jesteś programistą.

Doszedłem do tego momentu

Robiłem projekty od zera i walczyłem z okropnym kodem. Wymyśliłem:

TECHNICZNE RETRO

Pisząc kolejne projekty zastanawiałem się jak mierzyć dług techniczny. Skąd wiedzieć, że idziemy w dobrą stronę? Czytałem książki o testach, podejściu TDD i o byciu odpowiedzialnym za kod. Zacząłem podglądać jak managerowie robią retrospektywy, podsumowują wszystko.

I wpadłem na pomysł.

Co jeśli zaczniemy spisywać rzeczy dobre i złe? Jedna kolumna na miejsca, z których jesteśmy dumni a druga na to co się nie udało. Tak uczciwie. Co wyniknie?

Fajna i prawdopodobnie długa lista. Dług techniczny widoczny na pierwszy rzut oka. Do tego dodałem coś czego się nauczyłem od PM'ów. Trzecią kolumnę o nazwie "Akcje". Co mogę zrobić żeby było lepiej z tym kodem? Jak zmniejszyć nasz dług?

Co 2 lub 3 tygodnie robię tech retro w projektach gdzie pracuję. Staję się leaderem i pokazuję zespołowi, że musimy to zrobić. Po czasie naprawdę doceniają ten dokument. Historię kodu. Sami dopisują nowe akcje. Z pasją się chwalą co fajnego osiągneli i uczciwie przyznają co można poprawić.

Nagle legacy code staje się normalny, łatwy do ugryzienia skoro wiemy co jest nie tak.

Mój mały sukces

Jako developer można się cieszyć z wielu rzeczy. Na pewno z kodu. Ale ja się cieszę z moich małych sukcesów, kiedy wpływam na zespół i poprawiam nie tylko jakość kodu ale też ich samych. Stają się bardziej odpowiedzialni i w przyszłości będą lepszymi koderami.

Spróbujcie sami. Twórzcie swoje małe zwycięstwa.