Kilka lat temu, po niespełna 10 latach pracy jako programista, napisałem anglojęzyczny dokument zatytułowany „Craftsmanship of Software Development”, czyli „Rzemiosło tworzenia oprogramowania”. We wstępie wyjaśniłem dlaczego ten dokument powstał.
W trakcie mojej kariery jako programista nauczyłem się, często metodą prób i błędów, że wykonywanie pewnych rzeczy w określony sposób było bardziej efektywne, poprawiało jakość oraz ułatwiało pracę z moimi współpracownikami.
W pewnym momencie zacząłem postrzegać programowanie jako rzemiosło – niezwykle trudne do opanowania, szybko ewoluujące i bardzo wymagające. Pozwól, że pokażę Ci definicję „rzemieślnika” według internetowego Słownika Języka Polskiego:
Rzemieślnik – drobny wytwórca produkujący lub naprawiający różne przedmioty ręcznie lub z udziałem prostych narzędzi
Źródło: https://sjp.pl/rzemieślnik
Podoba mi się ta definicja. Czyż programiści nie są rzemieślnikami XXI wieku?
Ten dokument jest podsumowaniem moich przemyśleń związanych z pracą programisty. Wierzę, że przedstawione tutaj idee pozwolą każdemu deweloperowi osiągnąć miano mistrza rzemiosła w świecie tworzenia oprogramowania. Wszystkie poruszane tutaj tematy są niezależne od technologii – to znaczy, że nie ma znaczenia, w jakim języku programowania czy frameworku się specjalizujesz.
Podzieliłem treść tego dokumentu na Elementy, pogrupowane według tematyki, której dotyczą. Bardzo spodobał mi się koncept „Items” (ang. rzeczy/pozycje) z niezwykłej książki Effective Java, której autorem jest Joshua Bloch. Autor jasno przedstawił najlepsze praktyki dotyczące różnych paradygmatów i problemów związanych z programowaniem w Javie. W oparciu o ten pomysł stworzyłem Elementy, które moim zdaniem stanowią fundamenty do osiągnięcia statusu mistrza w rzemiośle, jakim jest programowanie. Sam jeszcze daleki jestem od tego tytułu, ale czuję, że zmierzam we właściwym kierunku.
Wszystkie przedstawione tutaj idee to moje własne przemyślenia. Opieram je na doświadczeniu zdobytym podczas pracy nad wieloma projektami na przestrzeni lat – może zgodzisz się z niektórymi, a inne uznasz za błędne. Chciałbym poznać Twoją opinię i będzie mi bardzo miło, jeśli się nią ze mną podzielisz. Chętnie przeczytam każdym komentarz pod tym wpisem i wiadomość e-mail, którą możesz wysłać na adres:
przemyslaw.kruglej@gmail.com
Tak zaczyna się mój dokument „Craftsmanship of Software Development”, który jest dostępny w Internecie pod następującym adresem:
https://craftsmanshipof.software
W dalszej części w pierwszej kolejności prezentuję cztery Elementy związane z jakością tworzonego oprogramowania. Oto pierwszy z nich.
Elementy jakości
Element #1 – Przekaż swój kod do „code review”¶
Ile razy widziałeś(aś) kod, który nie przestrzegał wytycznych projektu, nie był zgodny z najlepszymi praktykami, miał oczywiste błędy, albo po prostu nie był dobrze napisany? Wszystkie te problemy mogły zostać wykryte i naprawione podczas „code review”, czyli procesu przeglądu kodu źródłowego przez współpracowników. Są trzy główne powody, przez które tak się nie dzieje.
Po pierwsze, ludzie boją się krytyki, a właśnie tym często kończy się code review. Z drugiej strony, dobrze przeprowadzone code review poprawia jakość kodu i zmniejsza liczbę błędów. Moim zdaniem to właśnie jakość powinna być naszym głównym celem (Element #2 – Cel: jakość).
Jeśli tak jest w Twoim przypadku, to nie bój się code review. Znajdź współpracowników, którzy potrafią dawać konstruktywne opinie i będą starali się pomóc Ci ulepszyć Twój kod.
Po drugie, niektórzy programiści zdają się zapominać o jednej prostej prawdzie: każdy popełnia błędy, co potwierdza każdy wprowadzony do kodu bug (robak po angielsku, czyli błąd w kodzie programu). Wykaż się pokorą – niezależnie od tego, ile masz doświadczenia, Twój kod będzie czasem zawierał błędy. Wszyscy je popełniamy i nie ma nic złego w tym, że ktoś zwróci uwagę na problematyczny fragment kodu podczas code review.
Daj innym szansę na wykrycie błędu w Twoim kodzie zanim trafi on na produkcję.
Po trzecie, niektórzy programiści po prostu nie są przyzwyczajeni do code review i nie zdają sobie sprawy, jak bardzo może im to pomóc. Pamiętaj, że każdy recenzent kodu patrzy na niego z innej perspektywy – posiada inne umiejętności, doświadczenie, i wiedzę o projekcie. Dzięki temu może wykryć potencjalne błędy, którym można zapobiec już na etapie code review.
Oddawanie kodu do code review powinno być nawykiem – podnosi jakość kodu, który tworzysz, i pozwala na zaoszczędzenie dużej ilości czas na poprawę błędów w przyszłości.
Podsumowując: code review to wspaniały proces, który pozwala poprawić jakość tworzonego przez nas oprogramowania i zminimalizować liczbę błędów. Wystarczy, że dasz swoim współpracownikom szansę, by mogli przejrzeć Twój kod.
Za tydzień kontynuacja, czyli drugi „Element jakości”: Cel: jakość. Treść „Rzemiosła tworzenia oprogramowania” dostępna jest także w formie książki papierowej i e-booka (dokument PDF) w języku angielskim w moim sklepie.
A czy u Ciebie w pracy stosowany jest proces code review?