Code Review – parę słów na temat

Dzisiaj coś o Code Review, czyli przeglądaniu własnego kodu przez innego członka zespołu. Jak to działa?

Wyjaśnię to na podstawie Scrum’a. Rozpoczyna się sprint, każdy backlog item ma w sobie różne taski. Każdy task ma wyestymowany czas potrzebny na wykonanie zadania, np.

Handle operation documents

  • Create database structure 4h
  • Prepare model changes 2h
  • Create data structures 4h
  • Code Review 2h
  • Rework 3h

Jak widać, również Code Review oraz Rework jest wyestymowany.

Jak wygląda to w praktyce? Robimy pełen development backlog item’a, po czym informujemy kolegę/koleżankę z zespołu o tym fakcie. Następnie na podstawie naszych changeset’ów osoba, która przegląda kod jest w stanie zobaczyć co się zmieniło od ostatniej zmiany i w jaki sposób (w międzyczasie my zabieramy się za nowy item). Następnie zaznacza w kodzie miejsca, które należałoby poprawić/przemyśleć i dodaje komentarz. Taki komentarz, wraz z zaznaczonym miejscem znajduje się np. w work item’ach. Następnie startujemy z reworkiem naszego kodu. Jest to bardzo dobre podejście, ponieważ doświadczeni programiści mogą pokazać młodszym, że pewne rzeczy można zrobić lepiej, krócej, natomiast młodsi mogą pokazać starszym różne nowości. W ten sposób młodsi programiści tworzą co raz lepszy kod, natomiast starsi poznają rozwiązania dostępne w najnowszych wersjach framework’a. Klient zyskuje, ponieważ dostaje lepszy i czystszy kod. Zespół zyskuje, ponieważ wszelkie zmiany niosą ze sobą mniejsze konsekwencje (czy to w kodzie, czy to w teamie).

Win-Win.

6 uwag do wpisu “Code Review – parę słów na temat

  1. estymacja w godzinach? odważnie… 😛

    i co klientowi po lepszym i czystszym kodzie, kiedy mógłby dostać więcej funkcjonalności (wartości biznesowej) o wiele szybciej, za mniejsze pieniądze? (nie płaci za przytoczone 2h na CR – za te 2h może mieć pół kolejnego backlog item’a)

    czy nie tańszy jest wtedy pair programming?

    1. U mnie w firmie sprint trwa tydzień, więc estymacja w godzinach jest jak najbardziej na miejscu, nie wiem, jak u autora produktu.

      Wydaje mi się, że pair programming jest mniej opłacalny. Niby przekazywanie wiedzy również jest, ale sam po sobie wiem, że wolę spokojnie zrobić code review i przekazać wyniki, niż z kimś siedzieć i programować. Poza tym wydaje mi się, że w programowaniu w parach effort liczony jest razy dwa. A jak robisz code review, to ta druga osoba siedzi nad nastepnym itemem. A jak on przegląda Twoje zmiany – ty siedzisz nad kolejnym itemem.

      Po co klientowi lepszy i czysty kod? U nas przekonaliśmy klienta, że lepiej dłużej popracować i dostać lepszej jakości produkt, aniżeli na szybko, byle jak.
      Oczywiście klient nie widzi kodu. Ale lepiej pisać optymalnie, prawda?

      1. Podobnie, sprint trwa 10 dni, więc jakiekolwiek inne estymacje niż godzinowe nie wchodzą w grę. Co do optymalności w 100% się zgadzam, w dłuższej perspektywie projektowej obniża się w ten sposób koszty, gdy do zespołu wchodzi świeża osoba.

    2. Niekoniecznie. Takie rzeczy bierze się pod uwagę podczas fazy planowania, dlatego nie generują one dodatkowych kosztów. Co do godzin, to w momencie gdy mamy krótki sprint (7-12 dni) to jest to jedyne wyjście.

  2. U mnie sa sprinty 2 tygodniowe. Nikt nie estymuje w godzinach. Estymacja polega na przydzieleniu liczby z ciagu fibonacciego. Story jest albo latwie, srednie, trudne, bardzo trudne, nieokreslone. Liczby nie sa porownywanie miedzy zespolami bo nie ma to sensu. Kazdy zespol ma swoj velocity na ktorym opiera przyszle sprinty.

    Nie wyobrazam sobie programowania bez code review. Zawsze ktos gdzies tam od czasu do czasu musi przejrzec moje czarowanie w kodzie. Nie jestem idealem i robie bledy badz pisze kod na skroty.

    Do Code Review nie mozna jednak podchodzic w kategoriach strata czasu jak i nie mozna podchodzic stwierdzeniem ze code review musi byc zawsze. Ja jestem zwolennikiem podejscia pragmatycznego i mierzenia stosunku zysk / strata. W ten sposob zespol analizujac ryzykownosc zadania moze okreslic czy w ogole oplaca sie robic code review czy nie. Zadanie zadaniu nierowne. To tak jak z 100% code coverage ktore jest strata czasu i pieniedzy.

    Nie wyobrazam sobie programowania bez code review. Zawsze ktos gdzies tam od czasu do czasu musi przejrzec moje czarowanie w kodzie. Nie jestem idealem i robie bledy badz pisze kod na skroty.

    Do Code Review nie mozna jednak podchodzic w kategoriach strata czasu jak i nie mozna podchodzic stwierdzeniem ze code review musi byc zawsze. Ja jestem zwolennikiem podejscia pragmatycznego i mierzenia stosunku zysk / strata. W ten sposob zespol analizujac ryzykownosc zadania moze okreslic czy w ogole oplaca sie robic code review czy nie. Zadanie zadaniu nierowne. To tak jak z 100% code coverage ktore jest strata czasu i pieniedzy.

  3. Code review jak najbardziej. U nas sie robi review wiekszosci commit’ów.

    Natomiast nie uznaję estymowania czasu na code review, tak samo jak nie estymuje sie odzielnie zrobienia taska i napisania do niego testów. Code review jest u nas częścią zrobienia taska. i poprostu odzwierciedla się to w velocity.

Zostaw komentarz

Wprowadź swoje dane lub kliknij jedną z tych ikon, aby się zalogować:

Logo WordPress.com

Komentujesz korzystając z konta WordPress.com. Wyloguj /  Zmień )

Zdjęcie na Google+

Komentujesz korzystając z konta Google+. Wyloguj /  Zmień )

Zdjęcie z Twittera

Komentujesz korzystając z konta Twitter. Wyloguj /  Zmień )

Zdjęcie na Facebooku

Komentujesz korzystając z konta Facebook. Wyloguj /  Zmień )

Connecting to %s