Anatomien til å levere programvare til perfeksjon: hvordan kodegjennomgang fanget det testene ikke kunne

I løpet av et par uker leverte GeekBye ni utgivelser — v2.0.0 til v2.0.11 — og denne serien fortalte historien om hver enkelt av dem. Les dem sammen, og et mønster hopper frem som er mer interessant enn noen enkeltfeil: igjen og igjen besto et fiks hver eneste test på utviklerens maskin, og kodegjennomgangen beviste at det ville ha feilet for nesten alle andre.

Nettopp det gapet — mellom «det virker hos meg» og «det virker» — er der påliteligheten faktisk bor. Dette er arbeidsflyten som lukker det, og oversikten over hver eneste utgivelse den produserte.

Mønsteret: grønne tester, feil svar

Her er tre av de klareste tilfellene fra serien, fordi de gjør det abstrakte konkret.

• I fiksen for flerskjermsopptak (v2.0.10) forankret den første implementasjonen skjermopptaket i appens overleggsvindu. Det besto testingen — på en utviklermaskin med én skjerm. Gjennomgangen resonnerte om hvor det overlegget faktisk befinner seg (alltid på hovedskjermen, med mindre du fysisk drar det bort) og beviste at «fiksen» ville ha løst seg rett tilbake til feil skjerm for tilnærmet hver eneste reelle bruker. Det riktige ankeret — markøren — kom ut av det argumentet, ikke ut av en testkjøring.
• I WebSocket-reserveutgivelsen (v2.0.8) fant gjennomgangen at nettopp den 403 en blokkerende proxy returnerer ble klassifisert som en fatal autentiseringsfeil — så reserveløsningen funksjonen fantes for å utløse kunne aldri slå til. Funksjonen ville ha blitt levert, bestått sine happy path-tester og gjort ingenting for sitt faktiske publikum.
• I fiksen for inaktivitetstidsavbrudd (v2.0.9) stemplet den første versjonen «fortsatt i live»-klokken inne i en kodesti som en del av transkriptene legitimt hopper over — den andre talerens. Gjennomgangen fanget at en fremtidig endring stille kunne gjeninnføre nøyaktig den feilen som ble fikset, og stempelet ble flyttet til et sted uten betingelser, med en test for å holde det der.

Ingen av disse ble fanget ved å kjøre koden. Alle ble fanget av en gjennomgår som resonnerte om hvorfor koden virker — og fant et tilfelle der den ikke gjør det.

De tre delene av porten

Arbeidsflyten bak serien er ikke innviklet. Det er tre vaner som anvendes uten unntak.

1. Gjennomgang resonnerer om korrekthet, ikke bare kjører koden. En test som består beviser at koden virker for tilfellet du tenkte på. Gjennomgang er en andre, fiendtlig modell av systemet som spør: hvilket tilfelle tenkte du ikke på? — den andre skjermen, bedriftsproxyen, transkriptet som hopper over grenen, klienten som ligger én versjon bak. Gjennomgangssteget i denne serien var ofte en uavhengig agentgjennomgår som fikk beskjed om å tilbakevise fiksen, ikke velsigne den. Den innrammingen er hele poenget: en gjennomgår som prøver å bryte ned resonnementet ditt finner hullet en gjennomgår som prøver å godkjenne det skummer forbi.

2. Hvert atferdsfiks leveres med en test som spikrer den nøyaktige feilen. Ikke en test på at funksjonen virker — en test på at akkurat denne feilen er død. Den blokkerte proxyens 403 må falle gjennom til reserveløsningen; en ekte autentiserings-403 må ikke. Aktivitetsklokken må stemple på et transkript som hopper over tilskriving. Disse testene finnes for at feilen ikke skal kunne komme stille tilbake om et halvt år når noen refaktorerer i nærheten — feilen er spikret fast til gulvet.

3. Bygget er notarisert og verifisert før det leveres. Flere av disse fiksene gikk fra diagnose til en signert, notarisert, selvoppdaterende utgivelse i løpet av en dag. Den farten er bare trygg fordi porten er disiplinert: diagnostikken beviser rotårsaken (mikrofontillatelsesutgivelsen leverte sin diagnostikk først), testen spikrer fiksen, gjennomgangen tilbakeviser resonnementet, og først da går et ekte notarisert bygg ut. Grundighet er det som gjør fart trygt, ikke det som byttes bort mot den.

Hvorfor dette betyr mer for en AI-app

Det er en grunn til at denne disiplinen ikke er til forhandling for et verktøy som GeekBye spesifikt. Flere av de ekleste feilene i serien var stille-feil, ikke krasj-høylytte: et skjermbilde som matet feil skjerm til AI-en (v2.0.10), en transkripsjon som var vridd mot søppelbegreper slik at «snakke» kom ut som et navn (v2.0.11), en assistent som svarte i feil modus uten noen måte å se det på (v2.0.3 + v2.0.5). Når appen din mater kontekst til en modell, gir en feil inndata en selvsikkert feil utdata og ingen feil noe sted. Du kan ikke teste deg ut av feil som ikke kaster. Du må resonnere deg ut — som er nøyaktig det gjennomgangsporten er til for.

Serien, i rekkefølge

Hver av disse er en selvstendig casestudie av én utgivelse. Lest fra start til slutt er de anatomien til å ta et produkt fra «virker» til «til å stole på».

1. Hva en versjon 2 faktisk krever: 206 commits av ærlige tilstander — v2.0.0. Grunnmuren: vis aldri en tilstand som ikke er sann.
2. Dagen appen vår DDoS-et seg selv — v2.0.1 + v2.0.4. En oppstartsopplastingskø som stormet vår egen backend, og livstegn-stigen den tvang frem.
3. Rolig programvare: flimmerfiksen og svarmodus-brikken — v2.0.3 + v2.0.5. Utgivelser uten funksjoner som kjøpte tillit én detalj av gangen.
4. Mac-appen din glemmer mikrofontilgang ved hver oppstart — v2.0.6. macOS App Translocation, og å levere diagnostikken før fiksen.
5. Én CSS-variabel, fem gjennomgangsrunder og en Swift-verktøykjede som løy — v2.0.7. Ensartet gjennomsiktighet, og en binærfil som endret størrelse fordi dokumentasjonen var uenig med håndhevingsskriptet.
6. Livetranskripsjon når brannmuren blokkerer WebSockets — v2.0.8. En ren HTTPS-reserveløsning, og 403-en som ville ha skjult den for seg selv.
7. Hvorfor AI-notatverktøyet ditt slutter å ta opp midt i møtet — v2.0.9. En inaktivitetstimer som bare kunne høre deg, og en krasj som kunne låse skrivebordet ditt.
8. Hvorfor skjermopptak fanger feil skjerm — v2.0.10. Feil-skjerm-feilen, og fiksen som besto på én skjerm og ville ha feilet på to.
9. Hvorfor AI-transkripsjon hører tekniske termer feil — v2.0.11. Å vri tale mot ordforrådet ditt — og regresjonen som gjorde det verre før den gjorde det bedre.

Konklusjonen

Perfeksjon er ikke en tilstand du når; det er en port du opprettholder. Ni utgivelser, og de samme tre spørsmålene ved hver eneste: hvilket tilfelle tenkte du ikke på, er den nøyaktige feilen spikret av en test, og gikk det virkelig ut et ekte signert bygg? Ingenting av det er glamorøst. Alt av det er grunnen til at GeekBye v2 føles rolig. Hvis du bygger programvare — AI eller ikke — er den overførbare delen ikke noe enkelt fiks. Det er vanen med å behandle en grønn testpakke som begynnelsen på argumentet, ikke slutten på det.

Hver utgivelse over er tilgjengelig via automatisk oppdatering. For produktet disse fiksene summerer seg opp til, se hva som er nytt i GeekBye v2.