Kiedy rozpoczynałam pracę w którymkolwiek z moich większych projektów, ani razu nie zdarzyło mi się trafić na sytuację kiedy prace developerskie dopiero ruszały i nie było napisanego żadnego kodu. Trafiałam za to w miejsca, gdzie rozwój był już dość zaawansowany i niebawem miało wydarzyć się wydanie produkcyjne (czyli mówiąc po ludzku: umożliwienie użytkownikom końcowym korzystania z aplikacji) lub rozwój był już zakończony i praca polegała na utrzymywaniu projektu (naprawe błędów, dostosowaniu np. do nowszych wersji przeglądarek). Dzisiaj opowiem w jaki sposób odnajduję się w takim istniejącym oprogramowaniu.
Projekt projektowi nierówny
Wdrażanie się do konkretnego projektu bywało, w moim odczuciu, procesem bardzo krótkim i przyjemnym w jednym przypadku oraz bolesnym i frustrującym w innym. Z czego wynikały te różnice? Przede wszystkim z wykorzystywanych technologii, jak również z wielkości konkretnego przedsięwzięcia. Dla przykładu: kiedy w jednej z firm moim zadaniem było utrzymanie aplikacji webowej, która obejmowała wyłącznie warstwę front-endową napisaną w AngularzeJS, to moim jedynym zmartwieniem była nauka tego – już wtedy dość przestarzałego – frameworka.
Kiedy jednak wdrażałam się do mojego obecnego projektu to okazało się, że moją bolączką będzie nie tylko moja aplikacja, składająca się z frontu i back-endu (który oczywiście muszę sobie lokalnie zbudować i uruchomić), ale jeszcze z dziesięć innych osobnych bytów, które również muszę odpalić na swoim komputerze żeby móc normalnie korzystać ze swojej aplikacji. Oczywiście prace nad pozostałymi modułami trwają symultanicznie w innych zespołach i należy je regularnie uaktualniać, stawiać na nowo kontenery i starać się żeby 32 Gb pamięci RAM wystarczyło do codziennej pracy.
Tamten czas był dla mnie do tego stopnia stresujący, że obawiałam się czy w ogóle jestem w stanie zainstalować i uruchomić potrzebne komponenty, o pracy nad kodem nie wspominając. Na szczęście tamte frustracje mam już za sobą i wyciągnęłam z nich wiele wartościowego doświadczenia, które z pewnością przyda mi się nie raz w kolejnych projektach. Zatem co robię kiedy wdrażam się w projekt?
Dokumentacja
Z reguły każdy projekt, do którego trafiałam miał jakąś dokumentację. Przy małych aplikacjach był to np. plik tekstowy z informacjami o wykorzystanych technologiach i twórcach projektu. Zdarzało się, że miałam dostęp do archiwum z zapisem przebiegu projektowania całego przedsięwzięcia i było to kilka pdfów ze szczegółowymi informacjami biznesowymi. Niektóre projekty miały też jasno podaną instrukcję instalacji.
Dokumentacja mojego obecnego projektu składa się z ton dokumentów zebranych w kilku miejscach. Większość z nich jest zupełnie nieprzydatna na samym początku pracy, są jednak miejsca dedykowane instalacji projektu i te opisy są zupełnie zrozumiałe dla osób, które w tym projekcie pracują, a powiedzą bardzo niewiele komuś, kto dopiero się wdraża. Skrót myślowy „Do zalogowania się jako administrator systemu potrzebny jest import do xxx pliku xxx w xxx”, gdzie xxx to nazwy własne niewiadomego pochodzenia, wymaga solidnego wyjaśnienia i dlatego niezbędne jest…
Wsparcie osoby z zespołu
Najczęściej na początku zostawała mi przydzielana osoba, która była moim mentorem i jej mogłam zadawać wszelkie pytania. W obecnym projekcie korzystałam ze wsparcia kilku kolegów i na samym początku podjęłam rewelacyjną decyzję: zarchiwizowałam rozmowy dotyczące uruchamiania projektu. Wielokrotnie wracałam do nich w późniejszym czasie, ponieważ omawiały wiele standardowych procedur, które w późniejszym czasie musiałam wykonywać na bieżąco (np. restartowanie kontenerów czy ładowanie danych inicjalnych przez dedykowanego klienta).
Moje rozmowy „instalacyjne” podsyłałam także nowym kolegom, którzy dołączali do zespołu po mnie a mieli takie same rozterki związane z uruchomieniem środowiska. Okazuje się bowiem, że pewne triki nie trafiły nigdy do oficjalnej dokumentacji (która to bywa aktualizowana ze sporym opóźnieniem).
Wprowadzenie do projektu
Kiedy projekt został już zainstalowany i nawet się uruchamiał, nadszedł czas na stawienie czoła temu, co już zostało napisane. Miałam oczywiście mgliste pojęcie o tym, czym zajmuje się aplikacja, nad którą będę pracować, ale to jedynie teoria bez poparcia w kodzie. Następnie więc rozmawiałam z mentorem o tym jak aplikacja działa i jakie są główne wytyczne pracy. To był też moment na konfigurację edytora tak, aby działał zgodnie z wymaganiami i sam „odwalał” część pracy (np. edytował importy w pożądany sposób).
Wiedza zdobywana podczas rozmowy/rozmów z mentorem nie była dla mnie na początku w 100% zrozumiała. Ba, gdybym pojęła wtedy 50% tego co usłyszałam to i tak byłoby nieźle. Robiłam sobie notatki wypisując słowa klucze, które mogłyby mi się przydać w przyszłości (najczęściej tak właśnie było).
Czytanie kodu
Po tych wszystkich wstępach nadszedł moment na zerknięcie w kod. Projekty, którymi się zajmowałam miały dość oczywistą strukturę plików, dzięki czemu dość łatwo było się w nich odnaleźć. W przypadku aplikacji SPA czytanie zaczynam od routingu, tak żeby zorientować się co z czego wynika i o ile nie ma tam zaawansowanej magii, to wszystko układa się dość prosto. Następnie zaglądam w kolejne kontrolery i dochodzę w jaki sposób są budowane i jak działają. Przy okazji poznaję konwencje obowiązujące w projekcie. Jeżeli nie ma odrębnego style guide to kod będzie jedynym wyznacznikiem wykorzystywanych konwencji.
Znowu dokumentacja
Większe, bardziej złożone projekty poza dokumentacją instalacji posiadają również tzw. przypadki użycia (use cases), czyli opis interakcji pomiędzy użytkownikiem a systemem. Dla przykładu:
- System prosi Użytkownika o zalogowanie
- Użytkownik podaje swój numer identyfikacyjny oraz hasło
- System stwierdza poprawność danych
- Użytkownik zostaje zalogowany do systemu
źródło: Wikipedia
W moim obecnym projekcie poza programistami, testerami, scrum masterami, product ownerami etc. pracują również analitycy biznesowi, których głównym zadaniem jest przekładanie potrzeb klienta (zamawiającego oprogramowanie) na konkretne modele analityczne, na podstawie których tworzony jest kod. Modele te są skarbnicą wszelkiej wiedzy i wyrocznią w sporach 🙂
Pierwsze taski
Tak naprawdę czytanie teorii i cudzego kodu – choć bardzo pomocne – nigdy nie zastąpi mi samodzielnej pracy nad projektem. Dopiero kiedy dostałam realne zadanie do wykonania byłam zmuszona dokładnie poznać dany fragment aplikacji i zrozumieć jak ona działa. Im więcej wykonanych zadań, tym lepiej orientuję się co w trawie piszczy.
Code review
Jestem wielką fanką code review i zawsze jestem bardzo wdzięczna jeżeli ktoś da mi solidny feedback. Bardzo często, zwłaszcza w początkowych etapach pracy, moje rozwiązania były poprawne i oczywiście działały, ale np. miały niespodziewany dla mnie wpływ na inne miejsca w aplikacji, lub kod był niezgodny z konwencjami panującymi w projekcie (np. nie wykorzystywał istniejących utilsów). Code review pozwala na wyłapanie i poprawienie takich miejsc, a autorowi kodu daje możliwość zapoznania ze wskazaniami kolegów i wykorzystywanie ich w przyszłości.
Pair programming
Może to być pair a może być nawet group programming 🙂 Zdarzają mi się sytuacje (a na początku pracy zdarzały się bardzo, bardzo często), że nie jestem w stanie rozwiązać samodzielnie danego problemu i potrzebuję wsparcia innych programistów. Korzystam wtedy z dobrodziejstw Zooma lub MS Teams i dzielę swój ekran z osobą/osobami, z którymi rozmawiam i wspólnie staramy się znaleźć rozwiązanie.
Choć do dzisiaj lekko peszy mnie pisanie kodu, kiedy ktoś inny to obserwuje, to bardzo wiele uczę się podczas tego procesu: widzę jak piszą inni programiści, często słucham wypowiadanego na głos toku myślenia, poznaję meandry aplikacji, o których nie miałam pojęcia. Najczęściej kod pisze osoba, z którą rozmawiam a ja wtedy zadaję pytania.
Zaakceptowanie natury rzeczy
Każda firma i każdy projekt rządzi się swoimi prawami i choćbym nie wiem jak stawała na uszach, to pewnych rzeczy nie przeskoczę. Mój obecny projekt jest bardzo specyficzny, ponieważ powstaje na zlecenie instytucji rządowej, a konsekwencje takiego stanu rzeczy potrafią być zaskakujące.
Dla przykładu: przez prawie miesiąc oczekiwałam na komplet uwierzytelnień aby móc zacząć pracę. Kiedy już otrzymałam wszystkie niezbędne dostępy okazało się, że komputer z 16 Gb pamięci RAM jest za słaby, żeby projekt udźwignąć i musiałam czekać kolejne kilka dni na przysłanie nowego laptopa. No i wisienka na torcie: cały kod (!!!), który powstaje projekcie jest pisany w języku polskim. Takie wymagania.
Dlaczego o tym wspominam? Ponieważ pomimo moich najszczerszych chęci, zaangażowania i ciężkiej pracy zdarzały się, zdarzają i zdarzać się będą sytuacje kryzysowe, na które nie mam wpływu. Jeżeli więc nie zamierzam opuszczać projektu to nie pozostaje mi nic innego jak zaakceptowanie tego z dobrodziejstwem inwentarza oraz udzielenie sobie i ludziom wokół łaski wyrozumiałości w imię przyjemniejszej pracy 🙂