W dwóch poprzednich częściach naszej serii rozmawialiśmy o pierwszych krokach w zawodzie programisty oraz o tym, czego naprawdę warto się uczyć na początku kariery.
Teraz dochodzimy do momentu, którego obawia się niemal każdy Junior.
Pierwsze Code Review. Pierwsze komentarze do kodu. Pierwsze poprawki.
I pierwsza myśl: "Czy ja naprawdę aż tak źle napisałem ten kod?"
Spokojnie.
Każdy z nas kiedyś przez to przechodził.
Code Review nie jest egzaminem
To chyba największe nieporozumienie wśród początkujących programistów.
Wielu Juniorów odbiera komentarze do swojego kodu bardzo osobiście. Pojawia się stres. Niepewność. Czasem nawet frustracja.
A przecież celem Code Review nie jest udowodnienie komuś, że popełnił błąd. Wręcz przeciwnie. To jeden z najważniejszych elementów procesu tworzenia dobrego oprogramowania.
Dzięki Code Review:
- zmniejszamy ryzyko błędów,
- poprawiamy czytelność kodu,
- uczymy się od siebie nawzajem,
- dbamy o spójność całego projektu,
- przekazujemy wiedzę pomiędzy członkami zespołu.
Najlepsze zespoły nie traktują Code Review jako kontroli. Traktują je jako codzienną wymianę doświadczeń.
"Masz 37 komentarzy"
Brzmi groźnie? Na początku tak.
Pierwszy Pull Request często wygląda właśnie w ten sposób:
- Komentarz.
- Poprawka.
- Jeszcze jeden komentarz.
- Kolejna poprawka.
Po godzinie masz wrażenie, że cały kod nadaje się do wyrzucenia. To normalne.
Pamiętaj tylko o jednej rzeczy. Senior nie poprawia kodu dlatego, że chce pokazać swoją wyższość. Robi to dlatego, że za kilka miesięcy będziesz pisał znacznie lepszy kod.
I właśnie o to chodzi.
Dobry Senior nie mówi tylko "źle"
Najlepsi programiści, z którymi pracowaliśmy, zawsze tłumaczyli:
- dlaczego coś warto zrobić inaczej,
- jakie będą konsekwencje obecnego rozwiązania,
- jakie istnieją alternatywy,
- które rozwiązanie będzie łatwiejsze do utrzymania za rok lub dwa.
To ogromna różnica.
Bo można powiedzieć: "To jest źle."
A można powiedzieć: "To zadziała, ale jeżeli za pół roku będziemy rozwijać ten moduł, znacznie łatwiej będzie go utrzymać w takiej strukturze."
W drugim przypadku uczysz się czegoś znacznie cenniejszego niż samej poprawki. Uczysz się sposobu myślenia.
Clean Code nie oznacza pięknego kodu
To kolejne pojęcie, które bardzo często jest błędnie rozumiane.
Clean Code nie oznacza kodu, który wygląda efektownie. Nie chodzi o liczbę pustych linii. Nie chodzi o długość funkcji. Nie chodzi nawet o konkretne wzorce.
Chodzi o coś znacznie prostszego - kod powinien być czytelny.
Jeżeli za pół roku otworzysz własny projekt i nie będziesz pamiętał, co miałeś na myśli...
...to prawdopodobnie kod nie był wystarczająco czytelny.
Jest takie powiedzenie: Kod piszemy dla ludzi. Kompilator tylko sprawdza składnię.
I jest w tym bardzo dużo prawdy.
Nie zakochuj się we własnym kodzie
To jedna z najważniejszych lekcji.
Kod nie jest dziełem sztuki. Nie jest obrazem. Nie jest rzeźbą.
To narzędzie do rozwiązania konkretnego problemu.
Jeżeli ktoś proponuje lepsze rozwiązanie...
...warto je rozważyć.
Nie dlatego, że ktoś ma większy autorytet. Dlatego, że być może rzeczywiście jest lepsze.
Najwięcej uczą się ci programiści, którzy potrafią powiedzieć: "Masz rację. Zróbmy to inaczej."
"U mnie działa"
No dobrze. Musieliśmy w końcu dojść do tego słynnego zdania. Każdy software house ma swoją wersję tego żartu...
Wyobraź sobie sytuację.
Tester zgłasza błąd.
Programista odpowiada: "U mnie działa."
Tester sprawdza jeszcze raz. - Nie działa.
Project Manager patrzy. - Nie działa.
Klient również sprawdza. - Nie działa.
Ale... U autora kodu nadal działa.
Brzmi znajomo?
Najczęściej problem nie leży w samym kodzie.
Przyczyn może być bardzo wiele:
- inna wersja danych,
- inne środowisko,
- cache,
- konfiguracja,
- uprawnienia,
- przeglądarka,
- system operacyjny,
- przypadek, którego nikt wcześniej nie przewidział.
Dlatego profesjonalny programista nie kończy analizy na zdaniu: "U mnie działa."
Zadaje kolejne pytanie.
Dlaczego u mnie działa, a gdzie indziej nie?
I właśnie wtedy zaczyna się prawdziwe debugowanie.
"To tylko mała zmiana"
To kolejne zdanie, które budzi lekki uśmiech w większości software house'ów.
Klient mówi: "To tylko drobna poprawka."
Programista wie już, że za chwilę otworzy plik, którego nikt nie dotykał od sześciu lat.
A ta "drobna poprawka" okaże się zmianą w pięciu modułach, trzech integracjach i dwóch bazach danych.
Dlatego doświadczeni programiści bardzo ostrożnie podchodzą do słowa "tylko".
Najbardziej znane teksty z branży
Każdy zawód ma swoje powiedzenia. Programiści również.
Kilka z nich zna chyba każdy:
- "U mnie działa."
- "To tylko pięć minut."
- "To nie bug. To feature."
- "Przecież nic nie zmieniałem."
- "Na produkcji się wysypało."
- "Jeszcze tylko jeden deploy."
- "Na pewno cache."
- "Szybka poprawka przed weekendem."
- "To powinno działać."
I chyba najbardziej niebezpieczne: "Wrzucimy to na produkcję w piątek po 16:00."
Jeżeli pracujesz w IT...
...to prawdopodobnie właśnie się uśmiechnąłeś.
Programista nie pracuje sam
To temat, który często jest pomijany. W rzeczywistości większość projektów to praca zespołowa.
Programista współpracuje z:
- UX Designerami,
- UI Designerami,
- Project Managerami,
- Testerami,
- DevOpsami,
- Administratorami,
- Analitykami,
- Klientami.
Dlatego równie ważne jak znajomość technologii są:
- komunikacja,
- umiejętność słuchania,
- przekazywanie wiedzy,
- odpowiedzialność,
- wzajemny szacunek.
Najlepszy kod nie uratuje projektu, jeżeli zespół nie potrafi ze sobą współpracować.
Słowniczek pojęć
Code Review
Proces przeglądu kodu przez innych programistów przed jego wdrożeniem. Ma na celu poprawę jakości kodu, wykrycie błędów i dzielenie się wiedzą.
Pull Request (PR)
Propozycja wprowadzenia zmian do projektu. To właśnie na tym etapie najczęściej odbywa się Code Review.
Clean Code
Podejście do pisania kodu, którego głównym celem jest czytelność, prostota i łatwość utrzymania, a nie liczba zastosowanych wzorców projektowych.
Debugowanie (Debugging)
Proces odnajdywania i usuwania przyczyn błędów w aplikacji.
Cache
Mechanizm przechowujący dane tymczasowo w celu przyspieszenia działania aplikacji. Bywa również źródłem wielu zagadkowych problemów podczas testowania.
Podsumowanie
Im dłużej pracujemy jako programiści, tym bardziej dochodzimy do jednego wniosku. Najlepsi developerzy nie są tymi, którzy popełniają najmniej błędów.
Najlepsi developerzy potrafią:
- szybciej znajdować przyczynę problemu,
- wyciągać wnioski,
- uczyć się od innych,
- przyjmować konstruktywną krytykę,
- stale rozwijać swój warsztat.
Code Review nie jest więc przeszkodą. To jedna z najcenniejszych lekcji, jakie można otrzymać na początku swojej kariery.
W ostatniej części naszej serii porozmawiamy o tym, jak wygląda droga od Juniora do Seniora. Wyjaśnimy, dlaczego Senior Developer to nie osoba z dziesięcioletnim stażem, lecz ktoś, kto potrafi brać odpowiedzialność za projekt, myśleć biznesowo i pomagać rozwijać się innym członkom zespołu.
