JavaDevMatt.pl – Mateusz Kupilas

Programista, przedsiębiorca, gamedev, bloger.

Wdrażanie w istniejący projekt/kod – czyli jak zjeść słonia.

Każdy przez to kiedyś przejdzie, albo już przechodził (chyba, że miał wyjątkowe szczęście i zawsze mógł pisać projekt od zera) – wdrażanie do istniejącego projektu/kodu.

Nigdy nie wygląda to tak samo, ale trzymając się paru wskazówek możemy sobie ten proces trochę uprościć.

Oto przepis jak zjeść słonia.

Nie zaniedbaj konfiguracji

Konfiguracja projektu, który jest rozwijany od dłuższego czasu nie zawsze jest banalna. Często potrzebujesz różnych dodatkowych dostępów – np. miałem kiedyś w projekcie podpięty skrypt, który pobierał najnowsze tłumaczenia przy każdym budowaniu. Każdy użytkownik miał swój klucz, który musiał wrzucić do tego skryptu. Wszyscy developerzy nie mogli mieć tego samego – było to związane raportowaniem kto jakie zmiany wprowadził w tłumaczeniach: skrypt mógł też podmieniać różne tłumaczenia.

Jest to rzecz, której nie zrobisz samodzielnie. W Twoim interesie jest zadbać o to, by konfiguracja była zrobiona solidnie. Nie bój się o to męczyć kolegów – każdy jest zalatany i trzeba się czasami trochę poprzypominać. Musisz mieć wszystko wszystkie dostępy do baz danych, narzędzi używanych wewnątrz firmy (czasami wymagane są przydzielone licencje) etc. Samemu zdarzyło mi się to zaniedbać, brakowało mi czegoś, przez co cały proces działał, ale musiałem wykonywać trochę więcej pracy ręcznie. Jakoś odkładałem upomnienie się o parę dostępów i zmarnowałem przez kolejne tygodnie trochę czasu – nie miałem całego procesu tak zautomatyzowanego jak inni koledzy. Nie popełniaj tego błędu, bo będziesz „w plecy” od startu.

Zaczynasz od małych zadań i omawiasz je z kimś z projektu

Jak zjeść słonia? Po kawałku. Nawet gdyby był to słoń noworodek (ważą około 90-121kg), to raczej nie dałbyś rady. 😀

Jak w takim razie „zjadać po kawałku” projekt? Przez robienie małych zadań i konsultowanie ich z kimś z projektu. Cały proces wygląda mniej więcej tak:

  • Ktoś z projektu omawia z Tobą krótko zadanie. Pytasz z grubsza czego gdzie szukać.
  • Robisz te zadanie po swojemu. Ewentualnie zbierasz pytania, gdy nad czymś długo siedzisz (więcej o tych pytaniach w dalszej części wpisu).
  • Omawiasz Twoje rozwiązanie z kimś z projektu. Bardzo prawdopodobnie nie zauważyłeś, że np. w projekcie jest już coś, co napisałeś ponownie (np. jakieś utilsy do formatowania danych etc). I dobrze – ogarniasz projekt i właśnie przez praktykę nauczyłeś się, że coś takiego już istnieje. Wdrażasz się.
  • Poprawiasz Twoje rozwiązanie po konsultacjach z osobą z projektu (chyba, że wszystko poszło gładko od początku).
  • Konsultujesz poprawki z tą samą osobą. Powyższe dwa punkty powtarzasz do skutku.

Najlepiej, by zadanie dotyczyło frontendu: trudniej tam coś mocno popsuć. Nie usuniesz nieumyślnie danych z bazy. W najgorszym przypadku coś się nie wyświetli, albo wyświetli się krzywo. 😉 Takie zadania są idealny, by nowa osoba wgryzała się w projekt.

To chyba najlepszy sposób, by zacząć. Zamiast siedzieć cały dzień i bezcelowo „przeglądać projekt”, lepiej zabrać się za jakieś proste zadanie i postępować według powyższej listy.

Postaw sobie od zera projekt w tych samych technologiach

Czasami projekt ma dużo technologi, z których nigdy nie korzystałeś i trudno Ci załapać „big picture” – jak wszystko ze sobą właściwie działa.

Zamiast grzebać w takiej kobyle, warto czasami spróbować sobie postawić projekt z tymi samymi technologiami od zera. Będziesz wtedy widział cały proces łączenia wszystkich komponentów: na pewno zauważysz wtedy podobieństwa do Twojego dużego projektu.

Banalny przykład: gdy wrzuci się programistę Java do projektu z Androidem (bo akurat nie ma nikogo innego, a ktoś musi się tym zająć), to dobrze, by taki programista sobie postawił od zera projekt androidowy, by zobaczył jak te wszystkie klocki ze sobą współdziałają (lepiej to zrozumie, gdy sam je poukłada), widział jak dodaje się np. aktywności do manifestu etc.

 

Nie wywieraj na siebie niepotrzebnej presji – nie musisz rozumieć wszystkiego

NIGDY nie deklaruj nikomu, że „do następnego poniedziałku” będziesz już wszystko w danym projekcie rozumiał. To niepotrzebna presja i okłamywanie samego siebie. W przypadku dużego projektu normalne jest, że są fragmenty, których nigdy nie dotykałeś i ich aktualnie nie rozumiesz. Będziesz potrzebował tam coś zrobić, to zaczniesz to ogarniać (ewentualnie gdy będziesz miał trochę czasu i zajrzysz tam z ciekawości) i ewentualnie podpytasz kogo trzeba.

Rób sobie listę pytań, by ograniczyć przerywanie kolegom

Podczas pracy pojawiają się pytania. Rób sobie listę tych pytań, zamiast z każdym z osobna uderzać do jakiegoś kolegi. Ty będziesz miał większy komfort psychiczny, że kosztujesz innych mniej czasu (załatwiasz jednocześnie parę pytań z listy, a nie wyrywasz ich po jednym pytaniu) i koledzy docenią, że jesteś bardziej ogarnięty w swoim sposobie pracy. Niby banał, ale dużo osób tego nie robi.

Pair Programming

W pair programmingu dwóch programistów pracuje na jednym komputerze: jeden programuje, drugi jest „pilotem”, który robi taki „code review” na żywo, komentuje rozwiązanie etc. W normalnym przypadku co jakieś pół godziny powinniśmy zamieniać się rolami w takie metodzie programowania. Jednak w przypadku wdrażania się do projektu, warto więcej czasu posiedzieć jako pilot, który śledzi tryb pracy w projekcie i zadaje dużo pytań. Bycie takim pilotem w nowym projekcie, to bardzo dobry sposób by zrobić zacząć lepiej orientować się nowym kodzie źródłowy.

Źródło zdjęcia. By Lisamarie Babik (Ted & Ian  Uploaded by Edward) [CC BY 2.0 (http://creativecommons.org/licenses/by/2.0)], via Wikimedia Commons

Warto coś takiego zaproponować w ramach wdrożenia w nowy projekt.

To wszystko?

Z grubsza tak. Cudów nie ma: wdrożenie wymaga czasu. Nim programista bardziej doświadczony, tym łatwiej się wdraża, ale prawie zawsze takie wdrożenie będzie zależało nie tylko od Ciebie. Dużo zależy od tego jaką pomoc otrzymasz. Pamiętaj, że firmie zależy na tym, byś czuł się dobrze i sprawnie się wdrożył. Nigdy nie bój się pytać – lepiej mieć kogoś kto dużo pyta, niż kogoś kto dużo psuje (bo nie zapytał).

banerjd

3 thoughts on “Wdrażanie w istniejący projekt/kod – czyli jak zjeść słonia.

  • Marek pisze:

    Czekałem na ten wpis! 🙂

  • Kamil pisze:

    Trafiłeś z tym wpisem. Za miesiąc zmieniam pracę, więc takie rady zawsze się przydadzą.

  • Roman syn Ryżu pisze:

    Nie opłaca się słuchać rad innych. Im bardziej polegamy na sobie i słuchamy własnych odczuć, tym bardziej inteligentnie i świadomie reagujemy.
    Im bardziej słuchamy innych, tym mniej świadomie reagujemy. Zaczynamy kwestionować własne odczucia i staczamy się w wypalenie albo inne frustracje, zatracając pewność siebie.
    Stąd też pochodzi syndrom, który wcześniej opisywałeś.

Skomentuj Marek Anuluj pisanie odpowiedzi

Twój adres e-mail nie zostanie opublikowany. Wymagane pola są oznaczone *