Chciałbyś się rozwijać ale ciężko znaleźć czas na naukę? Chciałbyś by Twój kod nie zawierał błędów? Chciałbyś wiedzieć jak rozwiązać dany problem lepiej/wydajniej? Z tekstu dowiesz się czym jest Code Review i jakie daje efekty.
Code Review to analiza i feedback na temat czyjegoś kodu. Przed opublikowaniem swojego kodu oddajesz go do sprawdzenia przez kolegę z zespołu, lub osobę wyznaczoną przez lidera zespołu. Osoba ta analizuje Twój kod i wyłapuje ewentualne błędy. Jeśli obrana przez Ciebie ścieżka rozwiązania problemu wydaje się niezbyt trafiona, dowiesz się od tej osoby jak można to rozwiązać w inny, bardziej efektywny sposób.
Najważniejszym powodem wprowadzania Code Review w zespołach jest ulepszanie produktu, dzięki analizie kodu przez osoby z większym doświadczeniem. Dzięki temu, każda linijka przechodzi przez kilka par oczu, które wyłapują potencjalne błędy i problemy – czy to wydajnościowe czy architektoniczne.
Nie raz złapałeś się pewnie na tym, że Twój znajomy zauważył błąd, którego Ty nie widziałeś. Albo sytuację, w której masz pewien pomysł na rozwiązanie problemu, jednak po przedstawieniu go osobie trzeciej okazuje się, że można to zrobić w zupełnie inny, lepszy czy wydajniejszy sposób.
Ciężko jest samemu wyłapać swoje wszystkie błędy. Człowiek wzrokowo wyłapuje fragmenty swojego kodu i nie analizuje go linijka po linijce. Dopiero ktoś inny wyłapuje błędy, których my nie widzimy w naszym kodzie. Dobrze, by to była osoba z zespołu a nie klient. Dlatego tak wiele mówi się o „testowaniu na produkcji” 🙂
Mniej więcej na tej zasadzie działa Code Review. Oddając kod do analizy, w sposób pośredni rozmawiamy o kodzie. Taka rozmowa ma na celu wyciągnięcie wniosków co do jakości kodu i trafności wdrożonego rozwiązania. Dzięki takiemu podejściu więcej osób może przedstawić swoje pomysły i w końcu najlepsze rozwiązanie zostaje wdrożone do produktu.
Gdy oddajemy kod do analizy, w większości przypadków dostajemy feedback (rzadko okazuje się, że nic nie trzeba zmieniać). Czasami jest on pozytywny, częściej negatywny, ale zawsze rzeczowy i bardzo ważny. Dzięki takiej informacji zwrotnej najszybciej zdobędziemy cenne doświadczenie i nauczymy się nowych rzeczy.
Bez względu na to w jaki sposób się uczysz, zawsze to ktoś Ci przekazuje swoją wiedzę. Czy za pomocą książek, czy z filmów na YouTube. Jednak większość z tych źródeł jest jednostronna – dostajesz wiedzę i sam musisz ją „ogarnąć”. W przypadku Code Review jest inaczej. Masz możliwość dopytać audytora o to jak powinieneś coś zrobić. Przekazywanie informacji drogą perswazji oraz możliwość kontaktu bezpośredniego daje o wiele więcej możliwości przekazywania informacji oraz dopytywania o niezrozumiałe pojęcia.
Nie każdy ma czas na samodoskonalenie się w domu, w wolnym czasie, ale zawsze znajdziemy przysłowiowe 5 minut na to, by przedyskutować z kimś temat w biurze. Zdobyta tak wiedza jest nieoceniona.
Już! Jak najszybciej! Bardzo prosta odpowiedź bardzo trudnego pytania. Jedyny minus wprowadzenia Code Review jaki znam, to minimalne wydłużenie czasu wprowadzania kolejnych iteracji produktu na rynek. Jednak należy zastanowić się nad tym, czy: Chcesz wypuścić niedopracowany kod jak najszybciej się da, ale z możliwymi błędami? Czy wolałbyś mieć większą pewność co do jakości wprowadzanych rozwiązań, wydłużając nieco czas wdrożenia kolejnych iteracji (o powiedzmy 5%)?
Tak, mniej więcej tyle czasu wydłuży się czas wdrażania nowych funkcji. Przez ten czas zyskujesz natomiast aż tyle:
W perspektywie wielu firm, wydłużenie czasu wdrożenia kolejnych iteracji produktu jest marginalnym minusem w porównaniu z plusami jakie ze sobą niesie Code Review.
Polub stronę PHPCenter.pl by zyskać dostęp do najnowszych wiadomości ze świata PHP!
W internecie znajduje się masa programów, które koncentrują się na tym jak wykonać Code Review, jednak mając Gita, masz już narzędzie do Code Review.
Główną zasadą jest tworzenie feature branchy za każdym razem, gdy będziesz cokolwiek modyfikował. Bez względu na to, czy to jest zwykły bugfix czy duża funkcjonalność. Za każdym razem gdy stworzysz lub zmodyfikujesz kod, wysyłasz go do repozytorium. Dzięki temu, osoba która będzie miała wykonać audyt Twojego kodu, będzie mogła bez problemu pobrać tą gałąź i przeanalizować. Gdy dostaniesz feedback poprawiasz kod i ponownie wrzucasz do repozytorium.
Team Leader lub Project Manager powinien w tym miejscu odpowiadać za łączenie gałęzi poszczególnych developerów do głównego repozytorium, gdy dana funkcja przejdzie poprawnie Code Review. Dzięki temu, w zespole nie będzie samowolki i wszystkie dodawane funkcje będą kontrolowane.
Samo techniczne wdrożenie Code Review to jedno, a podejście osób z zespołu do komentowania i przyjmowania krytyki informacji o swojej pracy i kodzie to zupełnie coś innego.
Każdy z nas jest inny i do każdego należy podejść indywidualnie. Dlatego, chciałbym przedstawić Ci małe ale znaczące uwagi dotyczące tego, jak przekazywać informacje po audycie – jeśli jesteś audytorem – oraz jak je odbierać, jeśli to właśnie Ty jesteś programistą, który oddaje kod do sprawdzenia.
Pomimo tego, że każdy z nas jest inny, uwagi te są na tyle ogólne, że każdy powinien coś z nich wynieść.
Jeśli Tobie przypadnie rola audytora, pamiętaj, by dawany feedback nie był negatywną krytyką, a nauką dla autora kodu. Staraj się tak dobierać słowa by nauczać, a nie pouczać. Zamiast mówić „zrób to ‚tak’ i ‚tak’„, powiedz „zobacz, tutaj zrobiłeś ‚tak’, pomyśl co zrobiłbyś teraz, gdybyś musiał dodać jeszcze ‚to’ do tego kodu?„. Mam nadzieję, że mnie rozumiesz. Staraj się przedstawić swój punkt myślenia jako sugestię i staraj się zmusić autora kodu do myślenia – niech sam postara się wpaść na pomysł. Nakieruj go na pewne tropy. Uczmy przez eksplorację, a nie dyktowanie sztywnych zasad. W ostateczności pokaż mu co zyska tym rozwiązaniem.
Wiem, że to trudne i nie każdy się do tego nadaje. Jednak postaraj się stanąć na miejscu takiej osoby- chciałbyś słuchać cały czas, że robisz zły kod i wszystko jest do poprawki?
Jeśli Ty oddajesz kod do audytu i dostajesz feedback, nie bierz do siebie wszystkich słów audytora. Staraj się odbierać to jako naukę. Twój kod nie jest zły sam w sobie. W Code Review chodzi o to, by analizować kod i wspólnie starać się doprowadzić go do jak najlepszego stanu (słyszałeś o kodowaniu w parach? – Code Review możesz właśnie tak traktować). W tym konkretnym przypadku Twoje rozwiązanie może być nie na miejscu, jednak w innym będzie idealne.
Odbieranie feedbacku o swoim kodzie jest dla niektórych ciężkie – nie każdy jest w stanie „wybierać” z takich informacji zwrotnych to, co najważniejsze. Wiele osób za bardzo bierze do to do siebie i uważa, że nie nadaje się do niczego, bo dostają samą krytykę – a w cale tak nie jest! Pamiętaj jaka jest główna zasada Code Review – nauka i ulepszanie produktu przez cały zespół.
Da się tego nauczyć, wymaga to odrobiny samozaparcia – pamiętaj, że Code Review ma Cię czegoś nauczyć, zyskujesz doświadczenie w danym temacie.
Słuchaj, wyciągaj wnioski i ucz się od innych!
Bez względu na to, czy produkujesz CRM/ERP czy tworzycie strony internetowe, bez względu na to czy jesteś PM/TL czy zwykłym programistą, każdy może wdrożyć Code Review w zespole.
Jeśli zastanawiasz się na tym czy wprowadzić Code Review, albo nie jesteś osobą decyzyjną, zadziałaj na własną rękę. Spróbuj oddać kawałek kodu swojemu koledze obok. Porozmawiajcie czy zastosowane rozwiązanie jest dobre, czy może zna jakieś inne, które rozwiąże dany problem. Zobacz ile zyskasz gdy sam poprosisz kogoś o sprawdzenie swojego kodu, nawet jeśli nie praktykujecie tego w firmie.
A jeśli uważasz, że w Twoim przypadku Code Review nie ma sensu, napisz w komentarzu i przekonaj mnie do tego 🙂
Najbardziej dociekliwy członek zespołu. Zainteresowany rozwojem osobistym i bezpieczeństwem IT. Zakochał się w programowaniu DDD i CQRS. Pomysłodawca portalu phpcenter.pl, autor wielu artykułów i milionów linii kodu.
Polub naszą stronę aby dostawać powiadomienia o nowych, niesamowitych treściach!
