Jak bezboleśnie wdrożyć się w istniejący projekt? Subiektywne porady od software developera

Nie każdy ma szczęście dołączyć do projektu na jego początkowym etapie, kiedy to podejmowane są decyzje dotyczące architektury i zasad wspólnego tworzenia kodu. W swojej ponad 10-letniej karierze dołączałem do projektów o różnym stopniu zaawansowania i w różnych fazach realizacji. Chciałbym podzielić się z wami moimi przemyśleniami, w których uwzględniłem zarówno perspektywę developera, jak i dążenie do powodzenia samego projektu.

Nie ma projektów idealnych, a każda baza kodu może prędzej czy później skręcić w złym kierunku

Na poprzednich etapach mojej drogi zawodowej często traktowałem rozwiązania wykorzystywane przeze mnie wcześniej jako drogowskaz i wzór do tworzenia nowych projektów, niezależnie od ich specyfiki. Z czasem zauważyłem, że nie ma jednej słusznej drogi postępowania, która sprawdzi się w każdym przedsięwzięciu. Lekcja z tego jest taka, że dołączając do istniejącego projektu warto podchodzić do już wypracowanych w nim rozwiązań z dystansem i otwartą głową.

Trzeba tutaj warto zaznaczyć jedną ważną kwestię. Niektóre decyzje projektowe w momencie ich podejmowania są właściwe, jednak z biegiem czasu, po pojawieniu się nowych okoliczności ulegają dezaktualizacji. Ważne jest, by na bieżąco obserwować, w jakim kierunku projekt rozwija się i czy nie należy zmodyfikować obecnie stosowanych rozwiązań tak, by lepiej odpowiadały nowym realiom.

Ewolucja, nie rewolucja

Załóżmy, że poznaliśmy zasady panujące w projekcie, co pozwala nam lepiej zrozumieć, jak on działa. Jednocześnie nie do końca zgadzamy się z przyjętą implementacją lub decyzjami co do architektury. Jeśli zdecydujemy się na zgłoszenie tego problemu, to ważne, aby nasze pomysły miały charakter ewolucyjny, nie rewolucyjny. Rozpatrzmy prosty przykład.

Proponujemy wielką rewolucję, która ma doprowadzić do znacznego wzrostu jakości projektu, wymaga ona jednak przepisania większości aplikacji. Może okazać się, że mamy rację i w idealnym świecie implementacja powinna wyglądać tak, jak postulujemy. Natomiast nie ma czasu ani zasobów, aby takie zmiany przeprowadzić. Wtedy Twój pomysł może trafić na sam dół backlogu, skąd nie ma już powrotu.

Podejście drugie, ewolucyjne pozwoliłoby na wprowadzanie zmian po kolei, w najbardziej newralgicznych miejscach, przy pomocy niewielkich pull requestów. W ten sposób osiągniemy inkrementacyjny wzrost jakości i nie będziemy ograniczeni czasowo. Co więcej, nie narazimy siebie ani innych na wszelkiego rodzaju konflikty w kodzie, a to jest powszechna bolączka podejścia rewolucyjnego.

Oferty pracy z

Dokumentacja, transparentność i automatyzacja

Te trzy hasła mogą sprawić, że wdrożenie w nowy projekt oraz praca przy nim będą bardzo przyjemnym doświadczeniem. Symbolizują one obszary, na które warto zwrócić uwagę, gdy zależy nam na usprawnianiu pracy i szybszym wdrażaniu nowych osób.

Po pierwsze: dokumentacja. I nie mam tu na myśli jedynie dokumentacji kodu, ale także udokumentowanie decyzji dotyczących architektury oraz zasad wspólnej pracy nad repozytorium.

Po drugie: transparentność, np. w podejmowaniu decyzji projektowych. Skrupulatne prowadzenie ADR (Architecture Decision Record), czyli dokumentów opisujących wszystkie decyzje dotyczące architektury aplikacji pozwala członkom zespołu zrozumieć genezę konkretnych wyborów. Taka przejrzystość służy nie tylko nowym osobom dołączającym do projektu, ale też developerom z dłuższym stażem pracy, jak i członkom innych zespołów.

Innym przykładem transparentności jest konkretny opis wymagań stawianych przed wejściem kodu do repozytorium. Spisanie dobrych i złych praktyk w jednym dokumencie zawierającym zasady pisania wspólnego kodu oraz antywzorce wraz z ich uzasadnieniem również znacząco poprawia dalszą pracę nad kodem. Pozwala też przyspieszyć proces Code Review i zaoszczędzić czas – typowe błędy z czasem przestają być powtarzane.

Ostatnim z tych trzech obszarów jest automatyzacja. Praca programisty nie powinna polegać na formatowaniu kodu, ponieważ w większości przypadków można zautomatyzować ten proces, używając code formatera (np. Prettier) i tym samym pozbyć się zbędnych komentarzy w Code Review odnośnie tabów, spacji, grupowania importów itd. Wiele powtarzalnych czynności, takich jak update bibliotek w projekcie można również zautomatyzować, podobnie jak w sposób automatyczny uruchamiać unit testy przed próbą stworzenia commita. Dzięki temu osiągniemy wyższą jakość i spójność w projekcie.

Jakie praktyki polecam nowym członkom zespołu, którzy wchodzą w projekt?

1. Zesłanie na maintenance

W przypadku projektów, w których głównym źródłem wiedzy są informacje nigdzie nie udokumentowane, czyli tzw. „wiedza plemienna”, to często najlepsze rozwiązanie. W ten sposób nowy członek zespołu ma szansę poznać cały proces od podszewki, a także zidentyfikować etapy, przez które trzeba przejść, by proponowane w projekcie zmiany trafiły do środowiska produkcyjnego.

Jest to też świetna okazja, aby poznać i spisać „wiedzę plemienną”, a następnie podzielić się nią z nowymi osobami, które dołączą do zespołu.

Dlaczego uważam, że jest to lepsze zadanie na początek niż próba implementacji prostej funkcjonalności? Nie zawsze w backlogu projektu możemy znaleźć elementy łatwe do wdrożenia. Jednocześnie zadania w „maintenance” cechują się najczęściej konkretnie zdefiniowanymi wymaganiami i są znacznie prostsze, niż pełnowymiarowe taski.

2. Czytanie Merge Requestów

Merge requesty (te otwarte i już zamknięte) dostarczają informacji na temat tego, jak wygląda proces powstawania kodu oraz na co osoby recenzujące zmiany zwracają uwagę przed ich zaakceptowaniem. Dzięki temu nowy developer może nauczyć się kultury pracy w projekcie i szybciej jest gotowy do wspólnej pracy w zespole.

3. Pair Programming

Jeśli potraktować tę technikę jako formę mentoringu, to dla osoby dopiero co wchodzącej w projekt jest to rozwiązanie idealne. Pozwala zdobyć wiedzę techniczną i projektową oraz umożliwia poznanie pozostałych członków zespołu. A warto zauważyć, że rozmowy i interakcje między współpracownikami są kluczowe nie tylko dla powodzenia projektu, ale także dla wzmocnienia więzi i zwiększenia komfortu codziennej pracy.

Czy praca nad zmniejszaniem progu wejścia do projektu ma sens?

Moim zdaniem jak najbardziej. Czas poświęcony na zapewnienie transparentności i automatyzację procesów dość szybko się zwraca. Unikamy w ten sposób konieczności przekazywania „wiedzy plemiennej” pomiędzy programistami i zyskujemy więcej czasu na działania merytoryczne, zamiast na gwałtowne poszukiwanie tej konkretnej osoby, która jako jedyna w projekcie wie, jak coś działa i dlaczego. W efekcie developer może silniej skupić się na swoim zadaniu i szybciej dostarczyć wartość biznesową dla organizacji.

Zdjęcie główne artykułu pochodzi z unsplash.com.