Mi is valójában egy 127 commitos kiadás
A GeekBye v1.7.0 tizenegy nap alatt 127 commit volt. Kívülről ez száz apró dolognak tűnik. Belülről két nagy funkció összefonása volt — és az egyiket rossz helyre építettük, majd menet közben kitéptük és újraépítettük. Íme egy nagy kiadás anatómiája.
Van ennek a blogbejegyzésnek egy olyan verziója, amelyik csak felsorolja mindazt, ami a GeekBye v1.7.0-ban van — egy újratervezett kezdőképernyő, egy kalibrációs folyamat, egy összecsukható oldalsáv, új beállítások, és így tovább. Pontos lenne, és semmit sem tanítana neked. Mert egy 127 commitos kiadás őszinte története nem a lista. Hanem a forma.
Íme a forma. Százhuszonhét commit úgy hangzik, mint százhuszonhét apró dolog. Szinte soha nem az. A v1.7.0 két nagy funkció volt, párhuzamosan építve, hosszú életű brancheken, körülbelül tizenegy nap alatt, a végén összefonva. Egy nagy kiadás megértése azt jelenti, hogy megérted ezt a két szálat — és azt az egy helyet, ahol valamit rossz pontra építettünk, és menet közben ki kellett tépnünk.
Első szál: kalibráció
Az első szál a kalibráció volt — egy AI-alapú hangfelmérés a kommunikációs készségeidről. Elindítasz egy élő beszélgetést egy AI „karrier-coachcsal", végigmész egy strukturált fázissorozaton (bemelegítés, viselkedésalapú, technikai kommunikáció, nyomásreakció, célkitűzés), a végén pedig hat dimenzió mentén kapsz pontszámot: magabiztosság, tisztaság, konkrétság, elköteleződés, higgadtság, relevancia. A háttérben konkrét beszédmetrikákat is mér — a beszédtempódat, a töltelékszavak gyakoriságát, hogy a szüneteid stratégiainak vagy bizonytalannak hatnak-e.
A kimenet nem egy osztályzat, hanem egy kiindulópont. A kalibráció megadja az erősségeidet, a fejlődési területeidet, és — ami döntő — egy ajánlott nehézségi szintet, ahonnan érdemes elkezdened gyakorolni. Bekalibrálja, hol találkozzon veled a termék. Minden készség egy kibontható visszajelzési kártyaként tér vissza, egy összefoglalóval, egy konkrét javaslattal, és egy tényleges, idézett mondattal a saját beszélgetésedből példaként. Ez az a funkció, amelyre a gyakorlási élmény többi része épül.
Második szál: egy vadonatúj ablak
A második szál egy prémium újratervezés volt — és az újratervezés szó alábecsüli. Nem a meglévő képernyők átfestése volt; gyakorlatilag egy második alkalmazásablak volt, hat kifejezett fázisban kiépítve: egy összecsukható, Notion-stílusú oldalsáv, egy fejlécbeli legördülő menü, amely leváltotta a régi munkamenetlistát, böngészőstílusú navigáció előzményekkel és morzsamenükkel, valamint a Kezdőlap, a Profilok, a Meetingek és a Beállítások prémium újraépítése.
Két nagy funkció. Ez volt valójában a 127 commit. És a szállítás legnehezebb része nem egyikük megírása volt — hanem az összefonás. A két branch kölcsönösen függött egymástól; az egyiket beolvasztottuk a másikba, és a kalibrációs branchnek négy külön alkalommal kellett behúznia a main branchet, hogy ne sodródjon el, miközben az újratervezés alatta mozgott. A commitok száma nem egy nagy kiadás költsége. A hosszú életű branchek és az integráció sorrendje az.
A rész, amiért érdemes olvasni: rossz helyre építettük a kalibrációt
Íme a hiba, és ez egy jó hiba, mert annyira gyakori.
A GeekBye-nak van egy szilárd architekturális szabálya: minden AI-művelet a backenden lakik. A kliens egy vékony burok, amely egy szerverrel beszélget. Ezt mindenki tudta.
És a kalibrációt mégis először a kliens helyi adatbázisában építettük meg. Egy dedikált tábla, egy adatbázis-migráció, egy 254 soros repository, IPC-kezelők, és egy 515 soros felmérési kérdésbank — mind a felhasználó gépén lakva. Működött. És csendben megsértette azt a szerződést, amelyre az egész app épül.
Három nappal később egy commit 680 sort törölt nyolc fájlban, hogy az egészet áthelyezze a backendre, ahol a kalibrációs adatokból rendes szerveroldali modell lett, a kérdéslogika és a pontozás pedig szerveroldali ügy. Egy másik commit teljesen kitörölte az 515 soros kliensoldali kérdésbankot. A diff szinte vicces: egy beszúrás, hatszáznyolcvan törlés.
Senki sem indult neki azzal, hogy 680 sornyi eldobható kódot írjon. Úgy történt, ahogy ez mindig történik: a kliensoldali gyorsmegoldás ott van, gyorsabb helyben prototípust készíteni, és a „majd később áthelyezzük a backendre" ártalmatlannak tűnik. De amikor az architektúrád már megmondja, hol lakik az igazság forrása, bárhová máshová építeni nem gyorsmegoldás — hanem újramunka, amit előre beütemeztél magadnak. A tanulság, ami megmaradt: tedd oda, ahová a szerződés mondja, elsőre, még akkor is, ha a helyi verziót gyorsabb felállítani.
A hiba, amit csak az integráció találhatott meg
Még egy bizonyíték, mert ez a nagy kiadások jellegzetes hibázási módja. Amint a kalibráció és az új navigáció összedrótozódott, és ténylegesen futott, az app elkezdett átbillenni egy sebességkorláton — HTTP 429-eken — minden nyilvánvaló ok nélkül.
Az ok tiszta integráció volt. A kalibrációs státuszt komponensszinten kérdeztük le, így minden navigáció újralekérdezte — a React strict mode-ja pedig, amely szándékosan kétszer hívja meg az effekteket fejlesztés közben, hogy felszínre hozza a hibákat, ezt megint megkétszerezte. Az eredmény négytől nyolcig terjedő azonos kalibrációs kérés volt képernyőváltásonként, elég ahhoz, hogy átbillentse a szerver sebességkorlátozóját. A javítás a lekérdezést pár, felcsatoláskori hívásra konszolidálta.
Ezt a hibát nem találhattad volna meg úgy, hogy a kalibrációt teszteled önmagában, vagy a navigációt önmagában. Csak az illesztésnél létezik — ahol két, önmagában helyes funkció találkozik. Ez az az adó, amit egy nagy kiadás kivet: az utolsó kilométer nem a funkciók megépítése, hanem annak felfedezése, ami csak akkor törik el, amikor végre ugyanabban a szobában vannak.
Három dolog, amit egy nagy kiadás megtanított
- Egy 127 commitos kiadás két vagy három nagy téma, nem száz apró. Találd meg a szálakat. A munka — és a kockázat — abban lakik, ahogy összefonódnak, nem a számban.
- Tedd az igazság forrását oda, ahová a szerződés mondja, hogy lakik, elsőre. 680 sort töröltünk, hogy a kalibrációt kliensről backendre helyezzük át. A helyi gyorsmegoldás olyan újramunka, amit előre beütemeztél; az architektúra már megmondta a választ.
- Az integráció olyan hibákat hoz felszínre, amit az elszigetelés nem tud. A 429-es vihar a két helyes funkció közötti illesztésnél lakott, és csak akkor jelent meg, amikor együtt futottak. Számolj be egy integrációs menetre, ne csak a funkciónkénti tesztelésre.
Ez egy v1-korszakbeli unokatestvére egy történetnek, amit sokkal nagyobb léptékben mesélnénk el újra — lásd mit igényel valójában egy második verzió: 206 commitnyi őszinte állapot (v2.0.0), ahol ugyanaz a „egy nagy szám valójában néhány nagy ötlet" igazság játszódik le a teljes v2 újraíráson át. A v1-történet előző fejezetéért lásd hogyan streamelj egy élő jelentést villódzás nélkül (v1.6.13); a teljes ívért pedig a szoftver tökéletesre szállításának anatómiája.
