Anatomie dokonalého vydávání softwaru: Jak code review odhalil to, co testy nedokázaly

Během několika týdnů vydal GeekBye devět verzí — v2.0.0 až v2.0.11 — a tato série vyprávěla příběh každé z nich. Když je čtete pohromadě, vyskočí na vás vzorec zajímavější než jakákoli jednotlivá chyba: znovu a znovu oprava prošla všemi testy na vývojářově počítači a code review dokázal, že by selhala téměř u všech ostatních.

Právě v této mezeře — mezi „mně to funguje" a „funguje to" — se ve skutečnosti nachází spolehlivost. Toto je pracovní postup, který ji uzavírá, a rejstřík ke každému vydání, které vyprodukoval.

Vzorec: zelené testy, špatná odpověď

Zde jsou tři nejjasnější případy ze série, protože dělají to abstraktní konkrétním.

• V opravě zachytávání na více monitorech (v2.0.10) první implementace ukotvila zachytávání obrazovky na překryvné okno aplikace. Prošla testováním — na vývojářském počítači s jedním monitorem. Review uvážilo, kde toto překryvné okno ve skutečnosti sídlí (vždy na primárním displeji, pokud ho fyzicky nepřetáhnete), a dokázalo, že „oprava" by se u téměř každého skutečného uživatele vyhodnotila zpět na špatný monitor. Správná kotva — kurzor — vzešla z této argumentace, ne z běhu testu.
• Ve vydání s fallbackem přes WebSocket (v2.0.8) review zjistilo, že přesný 403, který vrací blokující proxy, byl klasifikován jako fatální chyba autentizace — takže fallback, kvůli němuž funkce existovala, se nikdy nemohl spustit. Funkce by byla vydána, prošla by testy šťastné cesty a pro své skutečné publikum by neudělala nic.
• V opravě timeoutu při nečinnosti (v2.0.9) první verze razítkovala hodiny „stále naživu" uvnitř cesty kódu, kterou část přepisů legitimně přeskakuje — přepisy druhého mluvčího. Review zachytilo, že budoucí změna by mohla tiše znovu zavést přesně tu chybu, která se opravovala, a razítko bylo přesunuto někam bezpodmínečného, s testem, který ho tam udrží.

Žádná z nich nebyla zachycena spuštěním kódu. Všechny byly zachyceny recenzentem, který uvažoval o tom, proč kód funguje — a našel případ, kdy nefunguje.

Tři části brány

Pracovní postup za sérií není nijak složitý. Jsou to tři návyky uplatňované bez výjimky.

1. Review uvažuje o správnosti, nejen spouští kód. Procházející test dokazuje, že kód funguje pro případ, na který jste mysleli. Review je druhý, adversariální model systému, který se ptá na jaký případ jste nepomysleli? — druhý monitor, firemní proxy, přepis, který přeskakuje větev, klient, který je o jednu verzi pozadu. Krok review v této sérii byl často nezávislý agent-recenzent, kterému bylo zadáno vyvrátit opravu, ne ji požehnat. Právě o toto rámování jde: recenzent, který se snaží prolomit vaši argumentaci, najde díru, kterou recenzent snažící se ji schválit přehlédne.

2. Každá oprava chování se vydává s testem, který přišpendlí přesné selhání. Ne test, že funkce funguje — test, že tato konkrétní chyba je mrtvá. Zablokovaný proxy 403 musí propadnout do fallbacku; skutečný autentizační 403 nesmí. Hodiny aktivity musí razítkovat i na přepisu, který přeskakuje atribuci. Tyto testy existují proto, aby se chyba nemohla za půl roku tiše vrátit, až bude někdo refaktorovat poblíž — selhání je přibité k podlaze.

3. Build je notarizovaný a ověřený před vydáním. Několik z těchto oprav se dostalo od diagnózy k podepsanému, notarizovanému, automaticky se aktualizujícímu vydání během jednoho dne. Tato rychlost je bezpečná jen proto, že je brána disciplinovaná: diagnostika dokáže kořenovou příčinu (vydání s oprávněním k mikrofonu vydalo svou diagnostiku jako první), test přišpendlí opravu, review vyvrátí argumentaci, a teprve pak jde ven skutečný notarizovaný build. Důkladnost je to, co dělá rychlost bezpečnou, ne to, co proti ní jde.

Proč na tom u aplikace s AI záleží víc

Existuje důvod, proč je tato disciplína nesmlouvavá právě pro nástroj jako GeekBye. Několik nejošklivějších chyb ze série bylo tiše-špatných, ne hlučně padajících: screenshot, který AI podstrčil špatný monitor (v2.0.10), přepis vychýlený k nesmyslným termínům, takže „speak" vyšlo jako jméno (v2.0.11), asistent odpovídající ve špatném režimu bez možnosti to poznat (v2.0.3 + v2.0.5). Když vaše aplikace předává kontext modelu, špatný vstup vyprodukuje sebejistě špatný výstup a nikde žádnou chybu. Ze selhání, která nevyhazují výjimku, se nedá vytestovat. Musíte se z nich vyargumentovat — a přesně od toho je kontrolní brána review.

Série, v pořadí

Každý z těchto článků je samostatnou případovou studií jednoho vydání. Přečtené od začátku do konce jsou anatomií toho, jak dostat produkt z „funguje" do „důvěryhodné".

1. Co ve skutečnosti obnáší verze 2: 206 commitů poctivých stavů — v2.0.0. Základ: nikdy nezobrazovat stav, který není pravdivý.
2. Den, kdy naše aplikace DDoSovala sama sebe — v2.0.1 + v2.0.4. Nahromaděné nahrávky při startu, které se hnaly na náš vlastní backend, a žebřík živosti, který si vynutily.
3. Klidný software: oprava blikání a čip režimu odpovědi — v2.0.3 + v2.0.5. Vydání bez nových funkcí, která kupovala důvěru po jednom detailu.
4. Vaše aplikace pro Mac zapomíná přístup k mikrofonu při každém spuštění — v2.0.6. App Translocation v macOS a vydání diagnostiky před opravou.
5. Jedna CSS proměnná, pět kol review a Swift toolchain, který lhal — v2.0.7. Jednotná průsvitnost a binárka, která změnila velikost, protože dokumentace nesouhlasila s vynucovacím skriptem.
6. Živý přepis, když firewall blokuje WebSockety — v2.0.8. Čistě HTTPS fallback a 403, který by ho schoval sám před sebou.
7. Proč váš AI zapisovač přestane nahrávat uprostřed schůzky — v2.0.9. Časovač nečinnosti, který slyšel jen vás, a pád, který mohl zamknout vaši plochu.
8. Proč nahrávání obrazovky zachytává špatný monitor — v2.0.10. Chyba se špatným displejem a oprava, která prošla na jednom monitoru a selhala by na dvou.
9. Proč AI přepis špatně slyší technické termíny — v2.0.11. Vychylování řeči k vaší slovní zásobě — a regrese, která to zhoršila, než to zlepšila.

Ponaučení

Dokonalost není stav, kterého dosáhnete; je to brána, kterou držíte. Devět vydání a stejné tři otázky u každého z nich: na jaký případ jste nepomysleli, je přesné selhání přišpendlené testem a vyšel opravdu ven skutečný podepsaný build? Nic z toho není okázalé. Všechno z toho je důvodem, proč GeekBye v2 působí klidně. Pokud stavíte software — s AI nebo bez ní — přenositelnou částí není žádná jednotlivá oprava. Je to návyk brát zelenou sadu testů jako začátek argumentu, ne jako jeho konec.

Každé z výše uvedených vydání je živé přes automatickou aktualizaci. Pro produkt, který z těchto oprav vzniká, se podívejte na co je nového v GeekBye v2.