A tökéletesre csiszolt szoftverszállítás anatómiája: hogyan kapta el a kódellenőrzés azt, amit a tesztek nem

Néhány hét alatt a GeekBye kilenc kiadást szállított — v2.0.0-tól v2.0.11-ig —, és ez a sorozat mindegyik történetét elmesélte. Olvasd őket együtt, és kiugrik egy minta, amely érdekesebb bármelyik egyedi hibánál: újra és újra egy javítás átment minden teszten a fejlesztő gépén, a kódellenőrzés pedig bebizonyította, hogy szinte mindenki másnál elbukott volna.

Ez a rés — a „nálam működik” és a „működik” között — az, ahol a megbízhatóság valójában él. Ez az a munkafolyamat, amely bezárja ezt a rést, és az általa létrehozott összes kiadás mutatója.

A minta: zöld tesztek, rossz válasz

Íme a sorozat három legvilágosabb esete, mert ezek teszik kézzelfoghatóvá az elvontat.

• A többmonitoros rögzítés javításában (v2.0.10) az első megvalósítás az alkalmazás overlay ablakához horgonyozta a képernyőrögzítést. Átment a teszten — egy egymonitoros fejlesztői gépen. Az ellenőrzés végiggondolta, hol is van valójában az az overlay (mindig az elsődleges kijelzőn, hacsak fizikailag át nem húzod), és bebizonyította, hogy a „javítás” szinte minden valódi felhasználónál egyenesen visszatért volna a rossz monitorra. A helyes horgony — a kurzor — ebből az érvelésből született, nem egy tesztfutásból.
• A WebSocket-tartalék kiadásban (v2.0.8) az ellenőrzés kiderítette, hogy pontosan azt a 403-at, amelyet egy blokkoló proxy ad vissza, végzetes hitelesítési hibaként osztályozták — így a tartalék, amelynek kiváltására a funkció létezett, soha nem indulhatott volna el. A funkció leszállt volna, átment volna a boldog-út tesztjein, és semmit nem tett volna a valódi közönségéért.
• Az tétlenségi időtúllépés javításában (v2.0.9) az első verzió a „még élek” órát olyan kódútba bélyegezte, amelyet a leiratok egy része jogosan átugrik — a másik beszélőé. Az ellenőrzés elkapta, hogy egy jövőbeli változtatás csendben visszahozhatta volna pontosan a javított hibát, ezért a bélyeg valami feltétel nélküli helyre került, egy teszttel, amely ott is tartja.

Ezek közül egyiket sem a kód futtatása kapta el. Mindegyiket egy ellenőr kapta el, aki arról érvelt, hogy miért működik a kód — és talált egy esetet, ahol nem.

A kapu három része

A sorozat mögötti munkafolyamat nem bonyolult. Három szokás, kivétel nélkül alkalmazva.

1. Az ellenőrzés a helyességről érvel, nem csak lefuttatja a kódot. Egy sikeres teszt bizonyítja, hogy a kód működik arra az esetre, amelyre gondoltál. Az ellenőrzés a rendszer egy második, ellenséges modellje, amely azt kérdezi, melyik esetre nem gondoltál? — a második monitorra, a vállalati proxyra, arra a leiratra, amely átugorja az ágat, arra a kliensre, amely egy verzióval lemaradt. Az ellenőrzési lépést ebben a sorozatban gyakran egy független ügynök-ellenőr végezte, akit arra utasítottak, hogy cáfolja meg a javítást, ne áldja meg. Ez a keretezés a lényeg: egy ellenőr, aki megpróbálja megtörni az érvelésedet, megtalálja azt a lyukat, amelyet egy jóváhagyni próbáló ellenőr átfut.

2. Minden viselkedésjavítás olyan teszttel érkezik, amely pontosan rögzíti a hibát. Nem olyan teszttel, hogy a funkció működik — hanem olyannal, hogy ez a konkrét hiba halott. A blokkolt proxy 403-ának át kell esnie a tartalékra; egy valódi hitelesítési 403-nak nem szabad. Az aktivitásórának bélyegeznie kell egy olyan leiratnál, amely átugorja az attribúciót. Ezek a tesztek azért léteznek, hogy a hiba ne térhessen vissza csendben fél év múlva, amikor valaki a közelben refaktorál — a hiba a padlóhoz van szegezve.

3. A buildet a szállítás előtt hitelesítik és ellenőrzik. E javítások közül több a diagnózistól egy aláírt, hitelesített, automatikusan frissülő kiadásig egyetlen nap alatt eljutott. Ez a sebesség csak azért biztonságos, mert a kapu fegyelmezett: a diagnosztika bizonyítja a gyökérokot (a mikrofonengedély kiadás először a diagnosztikáját szállította), a teszt rögzíti a javítást, az ellenőrzés megcáfolja az érvelést, és csak ezután megy ki egy valódi hitelesített build. A szigor az, ami biztonságossá teszi a sebességet, nem az, ami vele szemben áll.

Miért számít ez jobban egy AI-alkalmazásnál

Van oka annak, hogy ez a fegyelem kifejezetten egy olyan eszköznél, mint a GeekBye, nem alku tárgya. A sorozat legcsúnyább hibái közül több csendben-rossz volt, nem hangosan-összeomló: egy képernyőkép, amely a rossz monitort adta az AI-nak (v2.0.10), egy átirat, amely szemétszavak felé torzult, így a „speak” névként jött ki (v2.0.11), egy asszisztens, amely rossz módban válaszolt anélkül, hogy ezt látni lehetett volna (v2.0.3 + v2.0.5). Amikor az alkalmazásod kontextust ad egy modellnek, egy rossz bemenet magabiztosan rossz kimenetet állít elő, és sehol semmi hiba. Nem lehet kitesztelni magad olyan hibákból, amelyek nem dobnak kivételt. Ki kell érvelni magad belőlük — és pontosan ezért létezik az ellenőrzési kapu.

A sorozat, sorrendben

Ezek mindegyike önálló esettanulmány egy-egy kiadásról. Elejétől a végéig olvasva ez egy termék „működik” állapotból „megbízható” állapotba emelésének anatómiája.

1. Mit igényel valójában egy második verzió: 206 commit őszinte állapotokból — v2.0.0. Az alap: soha ne mutass olyan állapotot, amely nem igaz.
2. A nap, amikor az alkalmazásunk DDoS-olta önmagát — v2.0.1 + v2.0.4. Egy indításkori feltöltési torlódás, amely lerohanta a saját backendünket, és a válaszkészség-létra, amelyet kikényszerített.
3. Nyugodt szoftver: a villódzásjavítás és a válaszmód-jelvény — v2.0.3 + v2.0.5. Funkció nélküli kiadások, amelyek egy-egy részlet árán vették meg a bizalmat.
4. A Mac-alkalmazásod minden indításkor elfelejti a mikrofon-hozzáférést — v2.0.6. A macOS App Translocation, és a diagnosztika szállítása a javítás előtt.
5. Egy CSS-változó, öt ellenőrzési kör, és egy Swift eszközlánc, amely hazudott — v2.0.7. Egyenletes áttetszőség, és egy bináris, amely azért változtatta meg a méretét, mert a dokumentáció ellentmondott az érvényesítő szkriptnek.
6. Élő átirat, amikor a tűzfal blokkolja a WebSocketeket — v2.0.8. Egy tisztán HTTPS-alapú tartalék, és a 403, amely elrejtette volna önmaga elől.
7. Miért áll le az AI-jegyzetelőd a megbeszélés közepén — v2.0.9. Egy tétlenségi időzítő, amely csak téged hallott, és egy összeomlás, amely lezárhatta az asztali gépedet.
8. Miért rögzíti a képernyőrögzítés a rossz monitort — v2.0.10. A rossz-kijelző hiba, és a javítás, amely egy monitoron átment, de kettőn elbukott volna.
9. Miért érti félre az AI-átirat a technikai kifejezéseket — v2.0.11. A beszéd torzítása a saját szókincsed felé — és a regresszió, amely előbb rontott, mielőtt javított volna.

A tanulság

A tökéletesség nem egy állapot, amelyet elérsz; hanem egy kapu, amelyet fenntartasz. Kilenc kiadás, és mindegyiknél ugyanaz a három kérdés: melyik esetre nem gondoltál, rögzíti-e a pontos hibát egy teszt, és tényleg kiment-e egy valódi aláírt build? Semmi ebből nem látványos. Mégis ez az egész oka annak, hogy a GeekBye v2 nyugodtnak érződik. Ha szoftvert építesz — AI-t vagy bármi mást —, az átvihető rész nem egyetlen javítás. Hanem az a szokás, hogy egy zöld tesztkészletet az érvelés kezdetének tekintesz, nem a végének.

A fenti kiadások mind élnek automatikus frissítésen keresztül. Arról, hogy mivé állnak össze ezek a javítások, lásd: mi újság a GeekBye v2-ben.