Stanowisko
Developer
Jak długo trwa u Was, zanim nowa osoba w zespole wprowadzi pierwszą sensowną zmianę? Ta liczba mówi o Waszym kodzie i o dokumentacji więcej niż jakakolwiek metryka jakości.
Rozmowa wstępna
Cztery pytania, od których byśmy zaczęli
Jak długo trwa, zanim nowa osoba wprowadzi pierwszą zmianę?
Jeśli tygodnie, to koszt wdrożenia płacicie przy każdej rotacji, a rotacja w tym zawodzie jest faktem.
Co odkładacie pierwsze, kiedy termin się zbliża?
Zwykle testy i porządki w kodzie - czyli to, co zamienia się w dług, którego spłatę płaci następny kwartał.
Gdzie trafia wiedza o tym, dlaczego coś zrobiono właśnie tak?
Jeśli do rozmowy przy przeglądzie kodu, to za pół roku nikt nie będzie wiedział, czy to był wybór, czy przypadek.
Który rodzaj zadania powtarza się u Was najczęściej?
Zwykle są to trzy albo cztery wzorce - i zwykle nikt ich nie policzył.
Zdejmujemy prace powtarzalne, zostawiamy projektowanie i ocenę
Zrozumienie kontekstu kodu, szkice zmian powtarzalnych, przygotowanie testów i wstępny przegląd dają się odciążyć. Decyzje projektowe i ostateczna ocena kodu zostają przy człowieku.
- Kontekst przychodzi szybciej niż przez lekturę. - Co ten moduł robi, kto go zmieniał i jakie zmiany są z nim powiązane - zanim developer zacznie czytać linia po linii.
- Przegląd zaczyna się od tego, czego nie wyłapie lint ani CI. - Formatowanie i testy macie pewnie opanowane od dawna. Chodzi o warstwę wyżej: czy ta zmiana dotyka miejsc, których autor mógł nie zauważyć, i czy nie powtarza rozwiązania odrzuconego pół roku temu.
- Dług jest widoczny, a nie odczuwany. - Miejsca zmieniane najczęściej i te o najwyższej złożoności są wskazane, więc rozmowa o refaktorze ma podstawę.
Zakres
Co da się odciążyć w pracy zespołu developerskiego
Dziewiętnaście przykładowych zadań. Każde ma punkt zatwierdzenia po stronie człowieka. Poniżej wybrane, a zakres dopasowujemy do Waszego stosu i procesu.
Zrozumienie kodu i kontekstu
- Opis działania modułu na podstawie kodu (weryfikacja: developer)
- Wskazanie miejsc powiązanych ze zmienianym fragmentem
- Historia zmian w obszarze z powodami
- Wskazanie dokumentacji dotyczącej obszaru
Pisanie zmiany
- Szkic zmiany dla wzorców powtarzalnych (ocena i poprawa: developer)
- Propozycja testów do napisanej zmiany
- Wskazanie miejsc wymagających aktualizacji po zmianie
- Sygnał o zmianie naruszającej przyjęte konwencje
Przegląd kodu
- Wstępny przegląd przed przeglądem przez człowieka
- Wskazanie brakujących testów
- Wskazanie zmian dotykających miejsc powiązanych, o których autor mógł nie wiedzieć
- Zestawienie zmian do przejrzenia wedle ryzyka (decyzja: recenzent)
- Przypomnienie o przeglądzie oczekującym
Testy i wdrożenie
- Propozycja przypadków, których istniejące testy nie pokrywają
- Wskazanie testów, które przestały przechodzić i powodu zmiany zachowania
- Powiązanie zmiany z zadaniem i wydaniem
Dług techniczny
- Wskazanie obszarów zmienianych najczęściej
- Zestawienie miejsc o największej złożoności
- Powiązanie błędów produkcyjnych z obszarami kodu
Dzień pracy
Dzisiaj
- Przed zmianą czytacie moduł, żeby zrozumieć, co w ogóle robi
- Powiązane miejsca znajdujecie wyszukiwaniem i pamięcią zespołu
- Prace powtarzalne piszecie ręcznie, choć wyglądają tak samo
- Recenzent sam szuka, czego jeszcze dotyka ta zmiana
- Przegląd czeka dzień albo dwa, bo nikt nie wie, że czeka
- O długu technicznym mówicie na retrospektywie, bez danych
Z asystą AI
- Opis modułu i powiązane miejsca macie przed lekturą kodu
- Zmiana powtarzalna ma szkic, Wy go oceniacie i poprawiacie
- Testy do zmiany mają propozycję
- Powiązane miejsca są wskazane przy zmianie, nie szukane
- Oczekujący przegląd przypomina się sam
- Dług techniczny jest wskazany liczbami, nie wrażeniem
- Czas do pierwszej zmiany
nowa osoba wchodzi w kod szybciej
kontekst modułu jest dostępny bez lektury całości
- Czas oczekiwania na przegląd
zmiany nie leżą w kolejce niezauważone
przypomnienia i kolejność wedle ryzyka
- Jakość przeglądu
recenzent widzi zasięg zmiany, nie tylko diff
powiązane miejsca i historia decyzji są przy zmianie
- Widoczność długu
rozmowa o refaktorze ma podstawę liczbową
obszary zmieniane i złożone są wskazane
Zaczynamy od kontekstu i przeglądu, bo to najmniej ryzykowne i najszybciej odczuwalne.
- Krok 1
Kontekst kodu i powiązania
Opis modułów, historia zmian, miejsca powiązane.
- Krok 2
Wstępny przegląd i testy przed recenzją
Konwencje, brakujące testy, oczywiste błędy przed okiem człowieka.
- Krok 3
Szkice zmian powtarzalnych
Tylko wzorce, które naprawdę się powtarzają, i zawsze z oceną developera.
- Krok 4
Widoczność długu
Obszary zmieniane najczęściej i powiązanie z błędami produkcyjnymi. Na końcu, bo wymaga historii.
Częste pytania
Pytania, które padają na pierwszym spotkaniu
Co z kodem, którego nie wolno nam nigdzie wysyłać?
To częsty warunek i rozstrzyga się go na etapie architektury, a nie treści. Rozwiązania działające w Waszej infrastrukturze są realne; jeśli nie są, zakres ogranicza się do tego, co da się zrobić bez wysyłania kodu na zewnątrz. Tę rozmowę warto odbyć przed, a nie po.
To jest pytanie, które dziś zadaje cały rynek: czy AI zastąpi programistów?
Uczciwa odpowiedź: nie w zakresie, który tu opisujemy, i nie udajemy, że mamy odpowiedź na całe pytanie. To, co proponujemy, dotyczy kontekstu kodu, powtarzalnych wzorców i wstępnego przeglądu - czyli pracy, którą developer i tak uważa za najmniej interesującą. Decyzje projektowe, ocena kompromisów i odpowiedzialność za to, co trafia na produkcję, zostają po stronie zespołu. Jeśli zdejmiemy więcej niż to, stracicie na tym Wy, nie my - i dlatego granicę warto ustalić z zespołem, a nie za niego.
Czy to podlega AI Act?
Wytwarzanie oprogramowania nie jest zastosowaniem wysokiego ryzyka. Uwagi wymaga tylko to, żeby dane o zmianach w kodzie nie służyły do porównywania produktywności poszczególnych developerów - zestawienia prowadzimy wedle obszarów kodu, nie wedle autorów.
Zostało pytanie, którego tu nie ma? Umów rozmowę
Następny krok
Ile czasu Wasz zespół spędza na czytaniu kodu, zanim go zmieni?
Pokażemy Wam, jak wygląda praca zespołu, w której kontekst przychodzi wcześniej, a przegląd kodu zaczyna się od decyzji projektowych.