Co powiedziałbym sobie sprzed 20 lat, czyli 4 rady dla programisty

Dwadzieścia lat temu zaliczyłem pierwsze zlecenie jako programista freelancer. Dziś nadal zajmuję się tym samym. Z perspektywy czasu zauważam cztery nawyki, które, gdybym wiedział, wolałbym wykształcić w sobie wcześniej niż później.

Więcej automatyzuj

Jesteś dobry w byciu samowystarczalnym i potrafisz zachować w głowie tak wiele szczegółów i procesów. Deployment dla tego jednego klienta składa się z 15 kroków. Wykonujesz je co miesiąc, więc dobrze je pamiętasz. Wykonywanie ich zajmuje Ci każdorazowo 5 minut.

Będziesz wdawać się w debaty na ten temat ze swoimi współpracownikami. Wraz ze wszystkimi funkcjami, które wymagają zaprogramowania i wszystkimi błędami do naprawienia, będzie pojawiać następujące pytanie:

Czy naprawdę warto poświęcić czas na zautomatyzowanie czegoś, co zajmuje tylko kilka minut i jest wykonywane tylko raz na jakiś czas?

Nie myśl o tym w ten sposób. Zamiast tego pomyśl:

Wykonywanie tego procesu manualnie może zająć tylko 5 minut, raz w miesiącu. Automatyzacja dla tego procesu zajmie 3 godziny. Może to skrócić czas potrzebny do uruchomienia procesu z 5 minut do 3 minut.

I tu jest clue: 

Dzięki zautomatyzowaniu danego procesu nie musisz już go uruchamiać.

Zyskasz nie tylko 2 minuty w miesiącu. Twoje 5 minut może zamienić się w 0, ponieważ teraz, gdy proces jest zautomatyzowany, ktoś inny może poświęcić 3 minuty na jego uruchomienie.

Kiedy nadejdzie “godzina 0”, każdy w zespole, kto będzie miał 3 minuty wolnego, będzie mógł uruchomić ten zautomatyzowany proces.

Nie musisz robić wszystkiego. Jeśli coś zautomatyzujesz, inni będą mogli uruchamiać to za Ciebie, a Ty skupisz się na kolejnych rzeczach.

Więcej testuj

Ponieważ jesteś dobry w pamiętaniu o wszystkim, to jesteś też dobry w zapamiętywaniu każdego małego włącznika i przełącznika, którym należy “poruszać” za każdym razem, gdy tworzysz nową funkcję, tylko po to, aby upewnić się, że nic nie popsuło przy dopisywaniu nowego kodu.

Czy masz pewność, że o czymś nie zapominasz? A co, gdy ktoś inny doda trochę swojego kodu? Czy też będzie mieć listę rzeczy do przeklikania w celu przetestowania?

Na pewno coś przegapi. Będziesz zatem musiał przeklikać wszystko, co potrzeba za każdym razem, gdy ktoś zintegruje nowy kod.

Testowanie polega na dawaniu sobie pewności, że nowy kod nie zepsuje działającego starego kodu; pewności, że możesz zaimplementować kod bez budzenia się w środku nocy i mówienia do siebie:

„Kurka wodna, jeśli użytkownik kliknie ten przycisk po usunięciu metody płatności zamiast zrobić to wcześniej, to dostanie error. Muszę to naprawić”.

Tak, pisanie testów zajmuje trochę czasu. I pisanie testów w pierwszej kolejności nie jest tak satysfakcjonujące, jak kodowanie. Pomaga to jednak zachować porządek. Pisanie testów pozwala skupić się najpierw na tym, co rzeczywiście ma robić Twój kod.

Następnie możesz zaimplementować swój kod.

Testowanie polega na dawaniu sobie trochę przestrzeni we własnym umyśle, aby skupić się na refaktoryzacji i ulepszaniu kodu, ponieważ nie musisz już śledzić wszystkich tych łączników i przełączników, którymi trzeba manipulować, aby upewnić się, że refaktoryzacja niczego nie popsuje. 

Twoje testy zrobią to za Ciebie. Teraz nie musisz już martwić się refaktoryzacją. 

Tak przy okazji, dostajesz punkty bonusowe, jeśli wiesz, jak to połączyć:

więcej automatyzacji + więcej testowania = automatyzuj swoje testy

Dzięki automatyzacji testów, każdy może bezpiecznie dopisać swój kod i przeprowadzić testy - Ty, Twoi koledzy z zespołu oraz Twoi klienci. Będziesz przeprowadzać wszystkie procesy z większą pewnością siebie.

Otwórz się na innych 

Kiedy robiliśmy projekty grupowe na studiach, wszyscy wiedzieliśmy, że nasz kod był kiepski. Nikt z nas nie rozumiał, co tak naprawdę robimy. Debugowanie polegało na “przelatywaniu” przez linie kodu w nadziei, że coś samo się rozwiąże.

Jeśli jesteś freelancerem, widzisz cały kod. Prawdopodobnie tylko Ty widziałeś go od A do Z. To może powodować Twój brak pewności i strach, że coś się w nim posypie, bo możesz zaufać tylko sobie.

Ten strach i niepewność utrudniają Ci proszenie innych o pomoc, budowanie zespołu i przyjmowanie innych do projektu. Dzieje się tak, ponieważ nigdy nie poczujesz, że napisany przez Ciebie kod jest gotowy (wystarczająco dobry) do zrobienia pozytywnego wrażenia na innych programistach. Fakt, prawdopodobnie będą go krytykować. Powiedzą o różnych rzeczach, które zrobiliby inaczej.

Ten strach i niepewność będą Cię mocno ograniczać. Nie będziesz mógł uczyć się od innych, uczestniczyć w projektach i ogólnie się rozwijać.

Zmień to i otwórz się na innych. Poproś znajomych programistów, aby przyjrzeli się Twojemu kodowi. Zaakceptuj fakt, że może być on kiepski i spodziewaj się, że Twoi recenzenci to zauważą. Uodpornij się na to (ich kod też prawdopodobnie ma swoje gorsze momenty).

Co więcej, możesz też się łapać na czymś takim: „Chcę Ci pokazać ten moduł, który zbudowałem, ale daj mi jeszcze... 3 dni, żeby go trochę uporządkować.” Nie rób tego. Twój kod zawsze będzie można ulepszyć i nigdy nie będzie on idealny.

Nieustannie będziesz potrzebować więcej czasu, aby się przygotować. Staraj się zaakceptować swój kod tak, jak wygląda w danym momencie. Następnie poproś kogoś, aby go sprawdził.

Robiąc to wcześniej i częściej, zauważysz, że Twój kod zaczyna się poprawiać. Będzie się tak dziać, ponieważ podczas pisania zaczniesz przewidywać, jakie Twoje przyzwyczajenia skłaniają Twojego recenzenta do cringe'u lub płaczu. 

Twój kod nigdy nie będzie doskonały. Nie czekaj, aż taki będzie, zanim poprosisz kogoś, aby przejrzał Twój kod. W przeciwnym razie dzień ten nigdy nie nadejdzie.

Dziel się wiedzą 

Na drodze zawodowej spotkasz się z wieloma problemami i będziesz szukać rozwiązań w internecie. Nie zawsze znajdziesz rozwiązanie w taki sposób. Czasem trzeba pogrzebać w dokumentacji, bawić się różnymi konfiguracjami i próbować kreatywnie rozwiązać jakiś problem.

Potem możesz przejść do następnego problemu. Okradasz jednak świat - zwłaszcza jakiegoś konkretnego programistę, który będzie musiał zmierzyć się dokładnie z tym samym problemem. Okradasz go z rozwiązania, które znalazłeś.

Poświęciwszy tyle czasu na zdobycie wiedzy, nie pozwól, żeby przepadła. Nauczaj innych tego, czego sam się nauczyłeś.

Kent C. Dodds nazywa to „zwiększeniem wpływu Twojej wartości”. SWYX (Shawn Wang) nazywa to „publiczną nauką”.

Niezależnie od tego, czy piszesz samouczek, post na blogu, czy odpowiedź na Stack Overflow, powinieneś to jakoś zachować. Ktoś inny prawie na pewno z tego skorzysta. 

Ty też na tym skorzystasz. Tworząc pisemną formę swojego rozwiązania, niezależnie od tego, czy będzie to prezentacja, artykuł czy odpowiedź w danym wątku, utrwalisz sobie to rozwiązanie.

Pozwala to lepiej zagłębić się w problem. Zoptymalizujesz swoje początkowe rozwiązanie. Rozwiniesz się w sposobie przekazywania głębokich, niskopoziomowych koncepcji mniej doświadczonym osobom.

Będziesz odkrywać i tworzyć niesamowite rozwiązania trudnych problemów. To właśnie robisz dla swoich klientów.

Podsumowanie 

Podsumowując, podczas Twojej podróży jak programista freelancer przydadzą Ci się następujące rzeczy:

1. Więcej automatyzacji
2. Więcej testowania
3. Otwarcie się na innych
4. Dzielenie się wiedzą

Oryginał tekstu w języku angielskim przeczytasz tutaj.