Steven
Steven5 min czytania

Czym naprawdę jest wydanie ze 127 commitów

GeekBye v1.7.0 to 127 commitów w jedenaście dni. Z zewnątrz wygląda to jak sto drobnych rzeczy. Od środka były to dwie duże funkcje splecione ze sobą — a jedna z nich powstała w niewłaściwym miejscu, po czym została wyrwana i przebudowana w trakcie wydania. Oto anatomia dużego wydania.

Inżynieria
Wydanie
Architektura
Wydania GeekBye
Czym naprawdę jest wydanie ze 127 commitów

Istnieje wersja tego wpisu, która po prostu wylicza wszystko w GeekBye v1.7.0 — przeprojektowany ekran główny, przepływ kalibracji, zwijany pasek boczny, nowe ustawienia i tak dalej. Byłaby prawdziwa i niczego by cię nie nauczyła. Bo uczciwa historia wydania ze 127 commitów to nie lista. To kształt.

Oto kształt. Sto dwadzieścia siedem commitów brzmi jak sto dwadzieścia siedem drobnych rzeczy. Prawie nigdy nią nie jest. v1.7.0 to były dwie duże funkcje, budowane równolegle na długo żyjących gałęziach przez jakieś jedenaście dni, splecione ze sobą na końcu. Zrozumienie dużego wydania oznacza zrozumienie tych dwóch wątków — oraz tego jednego miejsca, w którym zbudowaliśmy coś w niewłaściwym punkcie i musieliśmy to wyrwać w trakcie lotu.

Wątek pierwszy: kalibracja

Pierwszym wątkiem była kalibracja — głosowa ocena AI twoich umiejętności komunikacyjnych. Zaczynasz rozmowę na żywo z „trenerem kariery" AI, przechodzisz przez ustrukturyzowany zestaw faz (rozgrzewka, część behawioralna, komunikacja techniczna, reakcja pod presją, wyznaczanie celów), a na końcu dostajesz ocenę w sześciu wymiarach: pewność siebie, klarowność, konkretność, zaangażowanie, opanowanie, trafność. Pod spodem mierzy też konkretne metryki mowy — tempo mówienia, częstotliwość słów-wypełniaczy, to, czy twoje pauzy czytają się jako strategiczne, czy niepewne.

Wynik to nie ocena, to punkt wyjścia. Kalibracja pokazuje twoje mocne strony, obszary do rozwoju i — co kluczowe — rekomendowany poziom trudności, od którego warto zacząć ćwiczyć. Kalibruje to, gdzie produkt powinien cię spotkać. Każda umiejętność wraca jako rozwijalna karta z opinią, z podsumowaniem, konkretną sugestią i faktycznie zacytowanym zdaniem z twojej własnej rozmowy jako przykładem. To funkcja, na której zbudowana jest reszta doświadczenia ćwiczeniowego.

Wątek drugi: całe nowe okno

Drugim wątkiem była przebudowa premium — i nazwanie tego przebudową jej nie oddaje. To nie był nowy wygląd istniejących ekranów; to było w istocie drugie okno aplikacji, rozbudowane w sześciu jawnych fazach: zwijany pasek boczny w stylu Notion, rozwijane menu w nagłówku, które zastąpiło starą listę sesji, nawigacja w stylu przeglądarki z historią i okruszkami oraz przebudowy premium ekranów Home, Profile, Spotkania i Ustawienia.

Dwie duże funkcje. Tym właśnie naprawdę było 127 commitów. A najtrudniejszą częścią ich dostarczenia nie było napisanie żadnej z nich — było splatanie. Obie gałęzie były współzależne; jedną scalono w drugą, a gałąź kalibracji musiała zaciągnąć główną gałąź cztery osobne razy tylko po to, by nie wypaść z synchronizacji, gdy przebudowa poruszała się pod nią. Liczba commitów to nie koszt dużego wydania. To długo żyjące gałęzie i kolejność integracji.

Część warta lektury: zbudowaliśmy kalibrację w niewłaściwym miejscu

Oto błąd, i to dobry, bo tak powszechny.

GeekBye ma twardą regułę architektoniczną: wszystkie operacje AI żyją na backendzie. Klient to cienka powłoka, która rozmawia z serwerem. Wszyscy to wiedzieli.

A jednak kalibrację zbudowano najpierw w lokalnej bazie danych klienta. Dedykowana tabela, migracja bazy danych, 254-liniowe repozytorium, handlery IPC i 515-liniowy bank pytań oceniających — wszystko żyjące na maszynie użytkownika. Działało. Po cichu naruszało też kontrakt, na którym zbudowana jest cała aplikacja.

Trzy dni później jeden commit usunął 680 linii w ośmiu plikach, by przenieść to wszystko na backend, gdzie dane kalibracji stały się właściwym modelem po stronie serwera, a logika pytań i punktacja stały się sprawą serwera. Kolejny commit usunął 515-liniowy bank pytań klienta w całości. Diff jest niemal zabawny: jedna wstawka, sześćset osiemdziesiąt usunięć.

Nikt nie zamierzał napisać 680 linii kodu do wyrzucenia. Stało się to tak, jak zawsze się to dzieje: skrót po stronie klienta jest na wyciągnięcie ręki, szybciej prototypuje się lokalnie, a „przeniesiemy to na backend później" wydaje się nieszkodliwe. Ale gdy twoja architektura już mówi ci, gdzie żyje źródło prawdy, budowanie tego gdziekolwiek indziej to nie skrót — to praca do przerobienia, którą sam sobie zaplanowałeś. Lekcja, która została: umieść to tam, gdzie mówi kontrakt, za pierwszym razem, nawet gdy lokalną wersję szybciej postawić.

Błąd, który mogła znaleźć tylko integracja

Jeszcze jeden dowód, bo to sygnaturowy tryb awarii dużych wydań. Gdy kalibracja i nowa nawigacja zostały ze sobą połączone i faktycznie działały, aplikacja zaczęła uruchamiać limit żądań — HTTP 429 — bez oczywistego powodu.

Przyczyna była czysto integracyjna. Status kalibracji był pobierany na poziomie komponentu, więc każda nawigacja pobierała go ponownie — a tryb strict Reacta, który celowo podwójnie wywołuje efekty w środowisku deweloperskim, by ujawnić błędy, zdublował to jeszcze raz. Rezultatem były od czterech do ośmiu identycznych żądań kalibracji odpalanych przy każdej zmianie ekranu, wystarczająco, by uruchomić limiter żądań serwera. Naprawa skonsolidowała pobieranie do kilku wywołań przy montowaniu.

Nie dało się znaleźć tego błędu, testując kalibrację samą lub nawigację samą. Istnieje tylko na szwie — tam, gdzie spotykają się dwie niezależnie poprawne funkcje. To podatek, który nalicza duże wydanie: ostatni odcinek to nie budowanie funkcji, to odkrywanie wszystkiego, co psuje się dopiero, gdy w końcu znajdą się w tym samym pokoju.

Trzy rzeczy, których nauczyło nas duże wydanie

  1. Wydanie ze 127 commitów to dwa lub trzy duże tematy, a nie sto drobnych. Znajdź wątki. Praca — i ryzyko — żyje w tym, jak się splatają, a nie w liczbie.
  2. Umieść źródło prawdy tam, gdzie mówi kontrakt, za pierwszym razem. Usunęliśmy 680 linii, przenosząc kalibrację z klienta na backend. Lokalny skrót to praca do przerobienia zaplanowana z góry; architektura już podała ci odpowiedź.
  3. Integracja ujawnia awarie, których izolacja nie potrafi. Burza 429 żyła na szwie między dwiema poprawnymi funkcjami i pojawiła się dopiero, gdy zaczęły działać razem. Zaplanuj budżet na przebieg integracyjny, a nie tylko testy każdej funkcji z osobna.

To kuzyn z epoki v1 historii, którą opowiedzielibyśmy ponownie w znacznie większej skali — zobacz czym naprawdę jest wersja druga: 206 commitów uczciwych stanów (v2.0.0), gdzie ta sama prawda „duża liczba to naprawdę kilka dużych pomysłów" rozgrywa się w całym przepisaniu v2. Po poprzedni rozdział historii v1 zobacz jak transmitować raport na żywo bez migotania (v1.6.13); a po cały łuk, anatomię dostarczania oprogramowania do perfekcji.