Anatomien bag at levere software til perfektion: hvordan kodegennemgang fangede det, testene ikke kunne

I løbet af et par uger leverede GeekBye ni udgivelser — v2.0.0 til og med v2.0.11 — og denne serie fortalte historien om hver enkelt. Læs dem samlet, og et mønster springer i øjnene, der er mere interessant end nogen enkelt fejl: igen og igen bestod en rettelse hver eneste test på udviklerens maskine, og kodegennemgangen beviste, at den ville være fejlet for næsten alle andre.

Netop den kløft — mellem "det virker for mig" og "det virker" — er der, hvor pålidelighed faktisk bor. Dette er arbejdsgangen, der lukker den, og indekset over hver udgivelse, den frembragte.

Mønsteret: grønne test, forkert svar

Her er tre af de tydeligste tilfælde fra serien, fordi de gør det abstrakte konkret.

• I rettelsen af optagelse på flere skærme (v2.0.10) forankrede den første implementering skærmoptagelsen på appens overlay-vindue. Den bestod testningen — på en udviklermaskine med én skærm. Gennemgangen ræsonnerede om, hvor det overlay faktisk befinder sig (altid på den primære skærm, medmindre du fysisk trækker det væk), og beviste, at "rettelsen" ville være endt tilbage på den forkerte skærm for næsten alle rigtige brugere. Det korrekte anker — markøren — kom ud af det argument, ikke ud af en testkørsel.
• I WebSocket-fallback-udgivelsen (v2.0.8) opdagede gennemgangen, at netop den 403, som en blokerende proxy returnerer, blev klassificeret som en fatal autentificeringsfejl — så den fallback, funktionen overhovedet fandtes for at udløse, aldrig kunne aktiveres. Funktionen ville være blevet leveret, bestået sine happy-path-test og ikke gjort noget for sit egentlige publikum.
• I rettelsen af inaktivitetstimeout (v2.0.9) stemplede den første version "stadig i live"-uret inde i en kodesti, som en delmængde af transskriptionerne legitimt springer over — den anden talers. Gennemgangen fangede, at en fremtidig ændring stille kunne genindføre præcis den fejl, der var ved at blive rettet, og stemplet blev flyttet et sted hen, hvor det var ubetinget, med en test til at holde det der.

Ingen af disse blev fanget ved at køre koden. Alle blev fanget af en gennemgåer, der ræsonnerede om hvorfor koden virker — og fandt et tilfælde, hvor den ikke gør.

Portens tre dele

Arbejdsgangen bag serien er ikke indviklet. Det er tre vaner, der anvendes uden undtagelse.

1. Gennemgangen ræsonnerer om korrekthed, den kører ikke bare koden. En bestået test beviser, at koden virker for det tilfælde, du tænkte på. Gennemgangen er en anden, adversariel model af systemet, der spørger hvilket tilfælde tænkte du ikke på? — den anden skærm, virksomhedsproxyen, transskriptionen, der springer grenen over, klienten, der er én version bagud. Gennemgangstrinnet i denne serie var ofte en uafhængig agent-gennemgåer, der fik til opgave at modbevise rettelsen, ikke velsigne den. Netop den indramning er hele pointen: en gennemgåer, der forsøger at bryde din ræsonnering, finder hullet, som en gennemgåer, der forsøger at godkende den, skimmer forbi.

2. Hver adfærdsrettelse leveres med en test, der fastnagler den præcise fejl. Ikke en test, der viser, at funktionen virker — en test, der viser, at netop denne fejl er død. Den blokerede proxys 403 skal falde igennem til fallbacken; en ægte autentificerings-403 må ikke. Aktivitetsuret skal stemple på en transskription, der springer attribueringen over. Disse test findes, så fejlen ikke kan vende stille tilbage om et halvt år, når nogen omstrukturerer i nærheden — fejlen er naglet til gulvet.

3. Buildet notariseres og verificeres, før det leveres. Flere af disse rettelser gik fra diagnose til en signeret, notariseret, automatisk opdaterende udgivelse inden for en dag. Den hastighed er kun sikker, fordi porten er disciplineret: diagnostikken beviser grundårsagen (mikrofontilladelses-udgivelsen leverede sin diagnostik først), testen fastnagler rettelsen, gennemgangen modbeviser ræsonneringen, og først derefter går et rigtigt notariseret build ud. Grundighed er det, der gør hastighed sikker, ikke det, der byttes væk for den.

Hvorfor det betyder mere for en AI-app

Der er en grund til, at denne disciplin er ikke til forhandling for netop et værktøj som GeekBye. Flere af de grimmeste fejl i serien var stille-forkerte, ikke højlydt-krakelerende: et skærmbillede, der fodrede den forkerte skærm til AI-en (v2.0.10), en transskription forudindtaget mod affaldstermer, så "speak" kom ud som et navn (v2.0.11), en assistent, der svarede i den forkerte tilstand uden nogen måde at se det på (v2.0.3 + v2.0.5). Når din app fodrer kontekst til en model, producerer en forkert indput et selvsikkert forkert output og ingen fejl nogen steder. Du kan ikke teste dig ud af fejl, der ikke kaster en undtagelse. Du er nødt til at ræsonnere dig ud — hvilket er præcis det, gennemgangsporten er til for.

Serien, i rækkefølge

Hver af disse er et selvstændigt casestudie om én udgivelse. Læst fra start til slut er de anatomien bag at føre et produkt fra "virker" til "til at stole på".

1. Hvad en version 2 faktisk kræver: 206 commits af ærlige tilstande — v2.0.0. Fundamentet: vis aldrig en tilstand, der ikke er sand.
2. Dagen vores app DDoS'ede sig selv — v2.0.1 + v2.0.4. En ophobning af opstarts-uploads, der stormede vores egen backend, og livstjek-stigen den fremtvang.
3. Rolig software: flimmer-rettelsen og svartilstands-chippen — v2.0.3 + v2.0.5. Udgivelser uden funktioner, der købte tillid én detalje ad gangen.
4. Din Mac-app glemmer mikrofonadgangen ved hver opstart — v2.0.6. macOS App Translocation, og at levere diagnostikken før rettelsen.
5. Én CSS-variabel, fem gennemgangsrunder og en Swift-værktøjskæde, der løj — v2.0.7. Ensartet gennemsigtighed, og en binær fil, der skiftede størrelse, fordi dokumentationen var uenig med håndhævelsesscriptet.
6. Live-transskription, når firewallen blokerer WebSockets — v2.0.8. En ren HTTPS-fallback, og den 403, der ville have skjult den for sig selv.
7. Hvorfor din AI-notetager stopper optagelsen midt i mødet — v2.0.9. En inaktivitetstimer, der kun kunne høre dig, og et nedbrud, der kunne låse dit skrivebord.
8. Hvorfor skærmoptagelse fanger den forkerte skærm — v2.0.10. Fejlen med den forkerte skærm, og rettelsen der bestod på én skærm og ville være fejlet på to.
9. Hvorfor AI-transskription hører tekniske termer forkert — v2.0.11. At forudindtage tale mod dit ordforråd — og regressionen, der gjorde det værre, før det blev bedre.

Konklusionen

Perfektion er ikke en tilstand, du når frem til; det er en port, du holder. Ni udgivelser og de samme tre spørgsmål ved hver eneste: hvilket tilfælde tænkte du ikke på, er den præcise fejl fastnaglet af en test, og gik der faktisk et rigtigt signeret build ud? Intet af det er prangende. Alt af det er grunden til, at GeekBye v2 føles roligt. Hvis du bygger software — AI eller ej — er den overførbare del ikke nogen enkelt rettelse. Det er vanen med at behandle en grøn testsuite som begyndelsen på argumentet, ikke enden på det.

Hver udgivelse ovenfor er live via automatisk opdatering. For det produkt, disse rettelser summerer op til, se hvad der er nyt i GeekBye v2.