Kto jest Twoim kumplem do kodowania?

Oryginalny post: Who's Your Coding Buddy?

Autor: Jeff Atwood

Zdumiewa mnie, jak bardzo mój kod zyskuje po tym jak zostanie przejrzany przez kogoś innego. Nie mam tu na myśli formalnej recenzji kodu, wysyłania go do publicznej oceny w Internecie lub uciążliwego reżimu programowania w parach. Jedna szybka próba wyjaśnienia i pokazania mojego kodu koledze/koleżance z zespołu -- to zazwyczaj wystarcza, by wyłapać błędy.

To oczywiście nie jest nic nowego. Doskonała książka autorstwa Karla Wiegersa Peer Reviews in Software: A Practical Guide opublikowana w roku 2002 jest kompletnym przewodnikiem na ten temat.

Peer Reviews in Software: a Practical Guide

Nie sądzę, by ktokolwiek podważał wartość spojrzenia innej osoby na twój kod, ale istnieją przeszkody, które zapobiegają praktykowaniu takich działań we wszystkich firmach. W rozdziale zatytułowanym A Little Help from Your Friends (pdf), Karl wyjaśnia:

Pracownicy czasami niechętnie poświęcają swój czas na sprawdzenie pracy kolegów. Możesz nie mieć zaufania do współpracownika, który prosi Cię o ocenę swojego kodu. Czy brakuje mu pewności siebie? Czy chce byś myślał za niego? "Każdemu, kto potrzebuje weryfikacji swojego kodu, nie powinno się płacić za bycie programistą", szydzą przeciwnicy recenzowania kodu.

W zdrowej kulturze programistycznej, członkowie zespołu angażują swoich współpracowników do poprawy jakości swojej pracy i poprawy wydajności. Rozumieją, że czas poświęcony nad oceną pracy kolegi zwraca się, kiedy inni członkowie zespołu oceniają rezultaty swojej pracy. Najlepsi programiści, których znam aktywnie poszukuja recenzentów swojej pracy . Istotnie, informacje zwrotne od wielu recenzentów w trakcie ich kariery były częścią tego, co sprawiło, że stali się najlepszymi.

Oprócz wymienionego wyżej rozdziału, możesz pobrać część rozdziału trzeciego (pdf) dzięki uprzejmości autora na stronie Process Impact. To nie jest wzięte z kosmosu. Za tym stoją rzeczywiste dane. Badania pokazują, że inspekcje kodu są zaskakująco efektywne.

Średni poziom wykrywania błędów wynosi tylko 25 procent dla testów jednostkowych, 35 procent dla testów funkcjonalnych i 45 procent dla testów regresyjnych. Średnia efektywność projektowania i inspekcji kodu to 55 i 66 procent..

Tak więc dlaczego nie wykonujesz recenzji kodu? Może dlatego, że nie wybrałeś jeszcze swojego kumpla do kodowania.

Pamiętasz te szkolne wycieczki, gdzie wszyscy byli upominani, by wybrali kolegę i trzymali się go? Miało to na celu zarówno uchronić nas od kłopotów jak i zapewnić nam bezpieczeństwo. Te same zasady mają również zastosowanie w budowaniu oprogramowania. Zanim wyślesz kod do repozytorium, daj go do sprawdzenia swojemu kumplowi. Czy umiesz wytłumaczyć ten kod? Może jest coś o czym zapomniałeś?

Jestem teraz zobowiązany przez prawo, by podać link do tego komiksu.

the only valid measurement of code quality: WTFs per minute

Jedyna poprawna miara jakości kodu: liczba słów WTF na minutę. Inspekcja kodu. Dobry kod: WTF, WTF. Zły kod: WTF, WTF, to jest do niczego, kolego WTF, WTF, WTF, WTF ...

Dziękuję Ci, spędzę tutaj cały tydzień.

Ten komiks ilustruje jak może wyglądać inspekcja, której potrzebujemy. Nie musi być skomplikowana, by była efektywna. Wartość WTF/minutę jest doskonale akceptowalną jednostką pomiarową, której możesz używać w pracy z twoim kumplem do kodowania. Społeczność XP (przyp. tłum. Extreme Programming) promuje programowanie w parach od lat, ale uważam, że posiadanie kumpla do kodowania jest dużo bardziej praktyczną drogą do osiągnięcia tych samych wyników.

Poza tym, kto nie chciałby być częścią wspaniałego programistycznego duetu?

Batman and Robin

To o wiele bardziej ekscytujące, niż perspektywa bycia przykutym do jednego komputera z drugą osobą. Pomyśl o wszystkich innych dynamicznych duetach jakie istnieją:

Jednostki mogą dokonać wielkich rzeczy, ale mogą osiągnąć jeszcze więcej, kiedy będą pracować razem. Na pewno jest przynajmniej jeden programista z którym pracujesz, którego podziwiasz lub przynajmniej darzysz szacunkiem wystarczającym, by został twoim kumplem do kodowania. Jeśli nie, rozważ zmianę firmy.

Jedną z uciech programowania jest to, że nie robisz tego sam. Tak więc kto jest twoim kumplem do kodowania?

Data publikacji oryginału: luty 25, 2009

4 komentarze:

Anonimowy pisze...

Zgadzam się w 100% najlepszą metodą oceny kodu jest pokazanie i wytłumaczenie komuś jak to działa, jeżeli zrozumie szybko to kod jest ok.

Anonimowy pisze...

Super artykuł. Ja też wyznaję zasadę, że czasem jak coś nie działa, to przydaje się komuś ponarzekać/wyjaśnić jak to działa i czasem wystarczy, że osoba nie mająca pojęcia o czym mówisz Cię wysłucha i sam wpadasz na rozwiązanie problemu :)
No ale taki kumpel(a) od programowania to by się przydał(a) na pewno :)

Paweł pisze...

bardzo ciekawa rzecz. ja sobie uświadomiłem, że od takiego kumpla od kodowania zacząłem swoją przygodę z programowaniem :-)

Krzysiek Wesołowski pisze...

@Anonimowy

bardzo często samo powiedzenie, "zwerbalizowanie" problemu powoduje, że zwrócisz uwagę na coś wcześniej pomijanego. Też wielokrotnie zawracałem komuś głowę znajdując rozwiązanie w połowie swojego wywodu :)

Prześlij komentarz

Related Posts with Thumbnails