Gdy kod piszą agenci, wąskim gardłem staje się przegląd

Zespół zaczyna używać agentów kodujących i pierwszy miesiąc jest znakomity. Zgłoszenia zajmujące dwa dni zajmują dwie godziny. Wszyscy są entuzjastyczni, a wykres prędkości to potwierdza.

Około drugiego miesiąca coś się zmienia. Pull requesty są większe. Przeglądy trwają dłużej i robią się płytsze. W obszarze, o którym nikt nie pamięta, żeby cokolwiek rozstrzygał, pojawia się defekt. Wykres prędkości nadal wygląda dobrze — i to jest część problemu.

Arytmetyka, której nikt nie robi

Generowanie przyspieszyło mniej więcej o rząd wielkości. Przegląd nie, bo przegląd to człowiek czytający kod i wyrabiający sobie sąd o tym, czy jest poprawny.

Jeśli zespół potrafił wyprodukować i przejrzeć cztery zmiany dziennie, a teraz produkuje czterdzieści, zdolność przeglądu się nie zmieniła. Opcje są trzy: przejrzeć porządnie cztery, przejrzeć pobieżnie czterdzieści albo być gdzieś pomiędzy i wmawiać sobie, że jest w porządku.

Większość zespołów wybiera trzecią i nie zauważa tego, bo pobieżny przegląd wygląda identycznie jak prawdziwy we wszystkich zbieranych miarach.

Jak wygląda niedoprzeglądany kod generowany

Wiarygodny i subtelnie błędny. Generowany kod jest idiomatyczny i dobrze ustrukturyzowany, co tłumi dokładnie te powierzchowne sygnały, po których recenzenci decydują, gdzie przyjrzeć się mocniej.

Poprawny lokalnie, niespójny globalnie. Każda zmiana z osobna jest sensowna. Dwadzieścia z nich wprowadza trzy różne sposoby robienia tego samego, a nikt nie widział wszystkich dwudziestu.

Przetestowany w niewłaściwy sposób. Testy wygenerowano razem z implementacją, z tego samego rozumienia — więc twierdzą, co kod robi, a nie co powinien robić.

Bez właściciela. Nikt nie umie wyjaśnić, dlaczego działa, bo nikt niczego nie rozstrzygnął — ktoś coś zatwierdził.

Traktowanie zdolności przeglądu jako ograniczenia

Praktyka, która działa, jest nieekscytująca i w większości dotyczy limitów.

Ograniczcie wielkość generowanych zmian. Na tyle małe, żeby dało się je porządnie przejrzeć. Jeśli zmiany nie da się zmniejszyć, jest to sygnał o specyfikacji, a nie o narzędziach.

Każda zmiana wiąże się ze specyfikacją. Recenzenci najpierw czytają intencję i kryteria akceptacji, a potem sprawdzają implementację względem nich. Przeglądanie diffa bez podanej intencji jest korektą tekstu.

Piszcie testy ze specyfikacji, a nie z implementacji. Niezależnie, najlepiej wcześniej. Inaczej zestaw testów jest lustrem i akceptuje wszystko, co zobaczy.

Mierzcie przegląd, nie generowanie. Liczbę zmian przejrzanych dziennie i czas każdej. Jeśli przepustowość generowania rośnie, a przeglądu stoi, luka gdzieś się gromadzi.

Trzymajcie widoczny zaległy stos do przeglądu. Jeśli rośnie, generowanie zwalnia. Ta reguła jest niepopularna przez tydzień i oszczędza kwartał.

Infografika

Zmiana, którą da się porządnie przejrzeć

1. 01SpecyfikacjaKażda zmiana wiąże się z intencją i kryteriami akceptacji.
2. 02Testy ze specyfikacjiPisane niezależnie od implementacji, najlepiej wcześniej.
3. 03Mała zmianaGenerowana na tyle mała, żeby dało się ją porządnie przejrzeć.
4. 04Przegląd względem intencjiNajpierw specyfikacja i kryteria, potem implementacja sprawdzana względem nich.
5. 05Widoczna zaległośćMierzony jest przegląd. Gdy stos do przeglądu rośnie, generowanie zwalnia.

Skąd naprawdę bierze się szybkość

Nie z szybszego pisania kodu. Z dystansu między rozstrzygnięciem, co ma być inaczej, a tym, że to działa — a on skraca się dramatycznie, gdy implementacja przestaje być ograniczeniem, i tylko wtedy, gdy ograniczeniem, które ją zastępuje, ktoś zarządza, zamiast je ignorować.

To jest cała przesłanka rozwoju sterowanego specyfikacją: specyfikacja staje się recenzowanym artefaktem, zdolność przeglądu jest tym, pod co wymiarujemy potok, a odpowiedzialność za to, co się scala, zostaje dokładnie tam, gdzie była.