Ce înseamnă cu adevărat o lansare de 127 de commit-uri

Există o versiune a acestei postări care doar înșiră tot ce e în GeekBye v1.7.0 — un ecran principal reproiectat, un flux de calibrare, un sidebar pliabil, setări noi și tot așa. Ar fi exactă și nu te-ar învăța nimic. Pentru că povestea onestă a unei lansări de 127 de commit-uri nu e lista. E forma.

Iată forma. O sută douăzeci și șapte de commit-uri sună ca o sută douăzeci și șapte de lucruri mărunte. Aproape niciodată nu e așa. v1.7.0 a fost două funcționalități mari, construite în paralel pe branch-uri de lungă durată de-a lungul a vreo unsprezece zile, împletite una în alta la final. A înțelege o lansare mare înseamnă a înțelege acele două fire — și acel singur loc în care am construit ceva în punctul greșit și a trebuit să-l smulgem înapoi în plin zbor.

Firul unu: calibrarea

Primul fir a fost calibrarea — o evaluare cu AI, pe voce, a abilităților tale de comunicare. Pornești un apel live cu un „coach de carieră" AI, parcurgi un set structurat de faze (încălzire, comportamental, comunicare tehnică, răspuns sub presiune, stabilirea obiectivelor), iar la final primești un scor pe șase dimensiuni: încredere, claritate, specificitate, implicare, calm, relevanță. Dedesubt măsoară și metrici concrete de vorbire — ritmul tău de vorbire, frecvența cuvintelor de umplutură, dacă pauzele tale sunt citite ca strategice sau ca ezitante.

Rezultatul nu e o notă, e un punct de plecare. Calibrarea îți produce punctele forte, zonele de creștere și — crucial — o dificultate recomandată de la care să începi să exersezi. Calibrează unde ar trebui produsul să te întâmpine. Fiecare abilitate revine ca un card de feedback expandabil, cu un rezumat, o sugestie concretă și o replică citată efectiv din propriul tău apel ca exemplu. Este funcționalitatea pe deasupra căreia e construită restul experienței de exersare.

Firul doi: o fereastră cu totul nouă

Al doilea fir a fost un redesign premium — iar să-l numim redesign îl subestimează. Nu a fost o reînveșmântare a ecranelor existente; a fost practic o a doua fereastră a aplicației, construită în șase faze explicite: un sidebar pliabil în stil Notion, un dropdown în header care a înlocuit vechea listă de sesiuni, navigare în stil browser cu istoric și breadcrumb-uri și reconstrucții premium ale ecranelor Home, Profiles, Meetings și Settings.

Două funcționalități mari. Asta au fost cu adevărat cele 127 de commit-uri. Iar partea cea mai grea a livrării lor nu a fost scrierea niciuneia — a fost împletirea. Cele două branch-uri erau interdependente; unul a fost făcut merge în celălalt, iar branch-ul de calibrare a trebuit să tragă branch-ul main de patru ori separate doar ca să nu ajungă desincronizat în timp ce redesign-ul se mișca dedesubtul lui. Numărul de commit-uri nu e costul unei lansări mari. Branch-urile de lungă durată și ordinea de integrare sunt.

Partea care merită citită: am construit calibrarea în locul greșit

Iată greșeala, și e una bună pentru că e atât de frecventă.

GeekBye are o regulă arhitecturală fermă: toate operațiunile AI stau pe backend. Clientul e o coajă subțire care vorbește cu un server. Toată lumea știa asta.

Și totuși calibrarea a fost construită mai întâi în baza de date locală a clientului. Un tabel dedicat, o migrare de bază de date, un repository de 254 de linii, handlere IPC și un bloc de 515 linii cu întrebări de evaluare — toate trăind pe mașina utilizatorului. Funcționa. Încălca și, în tăcere, contractul pe care e construită întreaga aplicație.

Trei zile mai târziu, un singur commit a șters 680 de linii în opt fișiere pentru a muta totul pe backend, unde datele de calibrare au devenit un model server-side ca lumea, iar logica întrebărilor și scorarea au devenit o preocupare a serverului. Un alt commit a șters de-a dreptul blocul de 515 linii cu întrebări de pe client. Diff-ul e aproape amuzant: o inserare, șase sute optzeci de ștergeri.

Nimeni nu și-a propus să scrie 680 de linii de cod de aruncat. S-a întâmplat așa cum se întâmplă mereu: scurtătura pe client e chiar acolo, e mai rapid să prototipezi local, iar „îl mutăm pe backend mai târziu" pare inofensiv. Dar când arhitectura ta îți spune deja unde stă sursa de adevăr, a-l construi oriunde altundeva nu e o scurtătură — e muncă suplimentară pe care ți-ai programat-o dinainte. Lecția care a rămas: pune-l acolo unde spune contractul, din prima, chiar și atunci când versiunea locală e mai rapidă de ridicat.

Bug-ul pe care doar integrarea îl putea găsi

Încă o dovadă, pentru că e modul de eșec caracteristic al lansărilor mari. Odată ce calibrarea și noua navigare au fost cablate împreună și au început să ruleze cu adevărat, aplicația a început să declanșeze o limită de rată — HTTP 429 — fără vreun motiv evident.

Cauza a fost pură integrare. Statusul calibrării era luat prin fetch la nivel de componentă, așa că fiecare navigare îl reîncărca — iar strict mode-ul React, care invocă intenționat efectele de două ori în dezvoltare pentru a scoate la iveală bug-uri, a dublat asta din nou. Rezultatul au fost patru până la opt cereri identice de calibrare trase la fiecare schimbare de ecran, suficient cât să declanșeze limitatorul de rată al serverului. Reparația a consolidat fetch-ul într-o pereche de apeluri la montare.

Nu ai fi putut găsi acest bug testând calibrarea singură, sau navigarea singură. Există doar la cusătură — acolo unde se întâlnesc două funcționalități corecte independent. Asta e taxa pe care o percepe o lansare mare: ultimul kilometru nu e construirea funcționalităților, e descoperirea a tot ce se strică doar când sunt în sfârșit în aceeași încăpere.

Trei lucruri pe care le-a predat o lansare mare

1. O lansare de 127 de commit-uri e două sau trei teme mari, nu o sută mărunte. Găsește firele. Munca — și riscul — stau în felul în care se împletesc, nu în număr.
2. Pune sursa de adevăr acolo unde spune contractul că îi e locul, din prima. Am șters 680 de linii mutând calibrarea de la client la backend. Scurtătura locală e muncă suplimentară programată dinainte; arhitectura îți spusese deja răspunsul.
3. Integrarea scoate la iveală eșecuri pe care izolarea nu le poate găsi. Furtuna de 429 trăia la cusătura dintre două funcționalități corecte și a apărut abia când au rulat împreună. Alocă buget pentru o trecere de integrare, nu doar pentru testare per funcționalitate.

Aceasta e o rudă din era v1 a unei povești pe care am spune-o din nou la o scară mult mai mare — vezi ce necesită cu adevărat o versiune 2: 206 commit-uri de stări oneste (v2.0.0), unde același adevăr „un număr mare e de fapt câteva idei mari" se joacă de-a lungul întregii rescrieri v2. Pentru capitolul anterior din povestea v1, cum transmiți un raport în timp real fără pâlpâire (v1.6.13); iar pentru întregul arc, anatomia livrării de software până la perfecțiune.