Hej! Każdy ze świata IT kiedyś robił jakiś dodatkowy projekt. Czasem było to coś małego, a czasem próby działania z wykorzystaniem nowych technologii Te nowe doświadczenia często pozwalają nam na nabycie wiedzy, którą możemy później wykorzystać w dalszej pracy. Zobrazuję to na prostym przykładzie.
Małe projekty
Często zaczynamy nowe projekty. Robimy trochę, potem przestajemy. Myślimy mocno, czy coś z tym zrobić dalej robić. Nieraz zostawiamy projekt, bo się nam po prostu znudził, a czasem tracimy zapał, motywację i po prostu przestajemy nad nim pracować.
Nie ma w tym nic złego, bo takie kilkukrotne rozpoczynanie projektu od nowa pozwala na dokładne utrwalenie naszej wiedzy. Ćwiczymy wtedy podstawowe etapy tworzenia projektu, tj.:
- założenie repozytorium projektu,
- utworzenie na nowo dockerowych kontenerów,
- utworzenie i połączenie z bazą danych,
- skonfigurowanie środowiska pracy.
To wszystko jest bardzo potrzebne i dobrze to umieć.
Gdy uczysz się nowej technologii lub wchodzisz w nowe tematy, np. Data Science, bardzo pożądane jest utrwalanie podstaw. Jak zrobisz kilka małych projektów od zera i za każdym razem przejdziesz pierwsze kroki życia projektu, to sobie dobrze je utrwalisz. Oczywiście za każdym razem popełnisz jakieś błędy, ale doświadczenie, jakie z tego wyniesiesz, pozwoli Ci na unikanie pomyłek lub szybką ich eliminację w trakcje kolejnych iteracji.
Minusy ciągłego rozpoczynania od początku
Największy minus tego rozwiązania to fakt, że rozpoczynamy i kończymy już na pierwszych etapach życia projektu. Załóżmy, że pracujemy nad projektem przez 2 tygodnie, a nawet miesiąc. Pewnie dobrze będziesz pamiętać, co się dzieje w kodzie. Jakie były założenia, dlaczego tutaj rozwiązaliśmy problem w taki sposób.
Nie ma sensu pisać dokumentacji prawda? Przecież i tak za 6 dni nie będę już pracować nad tym kodem. A poza tym kod sam o sobie opowiada!
I to jest największy problem małych i krótkich projektów. Nie piszemy komentarzy, dokumentacji i testów. Zazwyczaj mają one ograniczone przypadki użycia, więc nie zabezpieczamy kodu przed skrajnymi przypadkami i wyjątkami. Bo… po co?
Myśl do przodu!
Zachęcam Cię do rozpoczęcia pracy nad projektem trochę większym i bardziej skomplikowanym, takim trwającym np. pół roku. Jeżeli jednak nie masz zamiaru go robić, to zrób taki eksperyment myślowy.
Domyślam się, że inaczej podejdziesz już teraz do tematu komentowania i dokumentowania kodu. Spiszesz założenia projektu, to, co się w nim znajdzie, a co nie. Pewnie przydadzą się testy, w razie gdybyśmy chcieli zrobić refaktoryzację w przyszłości.
Wyobraź sobie sytuację, w której po 2 miesiącach wracasz do jakiegoś kawałka kodu. Będziesz pamiętać, o co dokładnie w nim chodziło? A jak się okaże, że nie realizujemy projektu sami? Współpracujemy z innymi osobami, którym teraz trzeba wszystko wytłumaczyć, bo nie ma żadnej dokumentacji? Są to sytuacje, które mogą nam zabrać sporo czasu i energii.
” Kod pisze się zazwyczaj raz, a potem czyta wiele razy.”
Jeżeli udokumentujesz kod, to będzie Ci się to zwracać za każdym razem kiedy Ty lub ktoś inny będzie do niego wracać.
W żyjącym projekcie brak dokumentacji, komentarzy czy testów, wcześniej czy później się na nas zemści. Poleganie na naszej pamięci nie jest dobrym pomysłem. Dużo lepiej jest zapisać, to co istotne, dzięki temu uwalniamy nasze „mózgowe zasoby” i mamy miejsce na nowe pomysły.
Co zyskasz?
Małe i krótkie projekty wnoszą do naszego życia:
- świeżość,
- niedużą presję,
- możliwość eksplorowania pomysłów i nowych technologii,
- utrwalanie początkowych etapów życia projektu.
Większe i długotrwałe projekty, niejako zmuszają nas do skupienia się na:
- zapisywaniu założeń i innych istotnych rzeczy, które są ważne przez cały cykl życia projektu;
- dokumentacji i komentowaniu kodu;
- pisaniu testów, aby utrzymać kompatybilność wstecz;
- przemyśleniu jak ten kawałek kodu, wpłynie na przyszłość;
- sposobach utrzymania kodu w dłuższym okresie czasu.
Uważam, że warto rozpoczynać oba typy projektów. Każdy z nich uczy nas czegoś innego i to jest po prostu kwestia proporcji i tego, czego nam akurat brakuje.
Jeżeli w pracy masz cały czas długoterminowe projekty, to super przyjemne będzie zrobienie czegoś krótkiego i mało obciążającego.
Natomiast, gdy np. na studiach robisz tylko, krótkie projekty, ciężko Ci będzie zdobyć umiejętności potrzebne w dużych projektach.
Tutaj nie ma dobrego i złego podejścia, róbmy to, co daje nam radość. A jak będziemy lubić to co robimy, to wiedza będzie przychodzić sama!
Zdjęcie wyróżniające wykonane przez Heike Mintel i zaciągnięte z Unsplash