Ohjelmiston toimittaminen täydellisyyteen asti – anatomia: miten koodikatselmointi löysi sen, mitä testit eivät löytäneet

Parin viikon aikana GeekBye toimitti yhdeksän julkaisua – v2.0.0:sta v2.0.11:een – ja tämä sarja kertoi jokaisen tarinan. Lue ne yhdessä, ja esiin hyppää kaava, joka on kiinnostavampi kuin yksikään yksittäinen bugi: kerta toisensa jälkeen korjaus läpäisi jokaisen testin kehittäjän koneella, ja koodikatselmointi todisti, että lähes kaikilla muilla se olisi epäonnistunut.

Juuri tuossa kuilussa – lauseiden "minulla se toimii" ja "se toimii" välissä – luotettavuus todella asuu. Tämä on työnkulku, joka sen sulkee, ja hakemisto jokaiseen julkaisuun, jonka se tuotti.

Kaava: vihreät testit, väärä vastaus

Tässä on kolme sarjan selkeintä tapausta, koska ne tekevät abstraktista konkreettista.

• Monimonitorikaappauksen korjauksessa (v2.0.10) ensimmäinen toteutus ankkuroi näytön kaappauksen sovelluksen peittoikkunaan. Se läpäisi testauksen – yhden monitorin kehityskoneella. Katselmointi päätteli, missä tuo peittoikkuna todellisuudessa sijaitsee (aina päänäytöllä, ellet fyysisesti raahaa sitä muualle), ja todisti, että "korjaus" olisi ratkennut takaisin väärään monitoriin lähes jokaisella todellisella käyttäjällä. Oikea ankkuri – kohdistin – syntyi tuosta päättelystä, ei testiajosta.
• WebSocket-varajulkaisussa (v2.0.8) katselmointi havaitsi, että juuri se 403, jonka estävä välityspalvelin palauttaa, oli luokiteltu kohtalokkaaksi todennusvirheeksi – joten varamekanismi, jonka laukaisemista varten ominaisuus oli olemassa, ei koskaan voinut käynnistyä. Ominaisuus olisi toimitettu, läpäissyt onnellisen polun testinsä eikä tehnyt mitään todelliselle yleisölleen.
• Joutenolon aikakatkaisun korjauksessa (v2.0.9) ensimmäinen versio leimasi "yhä elossa" -kellon koodipolulle, jonka osa litteroinneista ohittaa aivan perustellusti – toisen puhujan litteroinnit. Katselmointi huomasi, että tuleva muutos voisi hiljaa palauttaa juuri sen bugin, jota oltiin korjaamassa, ja leima siirrettiin johonkin ehdottomaan, testin kera pitämään se siellä.

Yhtäkään näistä ei löydetty ajamalla koodia. Kaikki löydettiin katselmoijan päätellessä, miksi koodi toimii – ja löytäessä tapauksen, jossa se ei toimi.

Portin kolme osaa

Sarjan taustalla oleva työnkulku ei ole monimutkainen. Se on kolme tapaa, joita sovelletaan poikkeuksetta.

1. Katselmointi päättelee oikeellisuutta, ei vain aja koodia. Läpäisevä testi todistaa, että koodi toimii tapauksessa, jonka keksit. Katselmointi on toinen, adversariaalinen malli järjestelmästä, joka kysyy: mitä tapausta et keksinyt? – toinen monitori, yrityksen välityspalvelin, litterointi, joka ohittaa haaran, asiakasohjelma, joka on yhden version jäljessä. Tämän sarjan katselmointivaihe oli usein riippumaton agenttikatselmoija, jota kehotettiin kumoamaan korjaus, ei siunaamaan sitä. Juuri tässä kehyksessä on koko pointti: katselmoija, joka yrittää murtaa päättelysi, löytää aukon, jonka ohi katselmoija, joka yrittää hyväksyä sen, luistaa.

2. Jokainen käyttäytymiskorjaus toimitetaan testin kanssa, joka naulaa tarkan epäonnistumisen. Ei testin, joka toteaa ominaisuuden toimivan – testin, joka toteaa, että tämä nimenomainen bugi on kuollut. Estetyn välityspalvelimen 403 täytyy pudota läpi varamekanismiin; todellisen todennuksen 403 ei saa. Aktiivisuuskellon täytyy leimata litterointi, joka ohittaa attribuoinnin. Nämä testit ovat olemassa, jotta bugi ei voi hiljaa palata puolen vuoden kuluttua, kun joku refaktoroi lähistöllä – epäonnistuminen on naulattu lattiaan.

3. Käännös notarisoidaan ja varmistetaan ennen toimitusta. Useat näistä korjauksista etenivät diagnoosista allekirjoitettuun, notarisoituun, automaattisesti päivittyvään julkaisuun yhden päivän sisällä. Tuo nopeus on turvallista vain siksi, että portti on kurinalainen: diagnostiikka todistaa perussyyn (mikrofonin käyttöoikeusjulkaisu toimitti diagnostiikkansa ensin), testi naulaa korjauksen, katselmointi kumoaa päättelyn, ja vasta sitten ulos lähtee todellinen notarisoitu käännös. Tarkkuus on se, mikä tekee nopeudesta turvallista, ei se, mikä käydään kaupaksi nopeutta vastaan.

Miksi tällä on suurempi merkitys tekoälysovellukselle

On olemassa syy, miksi tämä kuri on juuri GeekByen kaltaiselle työkalulle ehdoton. Useat sarjan ilkeimmistä bugeista olivat hiljaa-väärin, eivät kaatuen-äänekkäitä: kuvakaappaus, joka syötti väärän monitorin tekoälylle (v2.0.10), litterointi, joka oli vinoutunut roskatermeihin niin, että "puhua" tuli ulos nimenä (v2.0.11), avustaja, joka vastasi väärässä tilassa ilman mahdollisuutta nähdä sitä (v2.0.3 + v2.0.5). Kun sovelluksesi syöttää kontekstia mallille, väärä syöte tuottaa itsevarmasti väärän tulosteen ja ei minkäänlaista virhettä missään. Epäonnistumisia, jotka eivät heitä poikkeusta, ei voi testata pois. Ne on päätettävä pois – ja juuri sitä varten katselmointiportti on olemassa.

Sarja järjestyksessä

Jokainen näistä on itsenäinen tapaustutkimus yhdestä julkaisusta. Alusta loppuun luettuina ne ovat anatomia siitä, miten tuote viedään tilasta "toimii" tilaan "luotettava".

1. Mitä versio 2 oikeasti vaatii: 206 committia rehellisiä tiloja — v2.0.0. Perusta: älä koskaan näytä tilaa, joka ei ole totta.
2. Päivä, jona sovelluksemme DDoS-hyökkäsi itseensä — v2.0.1 + v2.0.4. Käynnistyksen latausruuhka, joka jyräsi oman taustapalvelumme, ja elossaolotikkaat, jotka se pakotti.
3. Rauhallinen ohjelmisto: välkyntäkorjaus ja vastaustilan merkki — v2.0.3 + v2.0.5. Ilman-ominaisuuksia-julkaisut, jotka ostivat luottamusta yksi yksityiskohta kerrallaan.
4. Mac-sovelluksesi unohtaa mikrofonin käyttöoikeuden joka käynnistyksellä — v2.0.6. macOS App Translocation ja diagnostiikan toimittaminen ennen korjausta.
5. Yksi CSS-muuttuja, viisi katselmointikierrosta ja Swift-työkaluketju, joka valehteli — v2.0.7. Tasainen läpikuultavuus ja binääri, joka muutti kokoaan, koska dokumentaatio oli eri mieltä kuin valvontaskripti.
6. Reaaliaikainen litterointi, kun palomuuri estää WebSocketit — v2.0.8. Puhtaasti HTTPS-pohjainen varamekanismi ja 403, joka olisi piilottanut sen itseltään.
7. Miksi tekoälymuistiinpanijasi lakkaa nauhoittamasta kesken kokouksen — v2.0.9. Joutenoloajastin, joka kuuli vain sinut, ja kaatuminen, joka saattoi lukita työpöytäsi.
8. Miksi näytön nauhoitus kaappaa väärän monitorin — v2.0.10. Väärän näytön bugi ja korjaus, joka läpäisi yhdellä monitorilla ja olisi epäonnistunut kahdella.
9. Miksi tekoälylitterointi kuulee teknisiä termejä väärin — v2.0.11. Puheen vinouttaminen omaa sanastoasi kohti – ja regressio, joka teki siitä huonomman ennen kuin teki siitä paremman.

Opetus

Täydellisyys ei ole tila, johon pääset; se on portti, jota ylläpidät. Yhdeksän julkaisua ja samat kolme kysymystä jokaisella: mitä tapausta et keksinyt, naulaako testi tarkan epäonnistumisen, ja lähtikö todella ulos oikea allekirjoitettu käännös? Mikään siitä ei ole hohdokasta. Kaikki se on syy siihen, miksi GeekBye v2 tuntuu rauhalliselta. Jos rakennat ohjelmistoa – tekoälyä tai muuta – siirrettävä osa ei ole yksikään yksittäinen korjaus. Se on tapa kohdella vihreää testijoukkoa argumentin alkuna, ei sen loppuna.

Jokainen yllä oleva julkaisu on saatavilla automaattipäivityksen kautta. Tuotteesta, joksi nämä korjaukset laskeutuvat yhteen, katso mitä uutta GeekBye v2:ssa.