Mit Igényel Valójában egy Második Verzió: 206 Commit Őszinte Állapotokból

A legtöbb „második verzió" kiadás egy halom új funkció, nagyobb számmal rajtuk. A GeekBye v2 épp az ellenkezője volt. Szinte semmilyen új, felhasználó számára látható képességet nem szállított. A 206 commitja egyetlen, egyáltalán nem látványos gondolat felé irányult:

Az alkalmazás soha ne mutasson olyan állapotot, ami nem igaz.

Ez nyilvánvalónak hangzik, amíg meg nem számolod, hányféleképpen hazudik csendben egy asztali alkalmazás. Pipát mutat egy feltöltésre, ami még úton van. Azt mondja, „csatlakozva" egy socketen, ami egy perce meghalt. Néma marad, miközben az átiratodat a földre ejtik. Egyik sem összeomlás. Rosszabbak az összeomlásnál, mert az alkalmazás rendben lévőnek tűnik, miközben téved — és csak később derül ki, amikor a felvétel, amire szükséged volt, nincs ott.

A v2 volt az a kiadás, ahol vadászni indultunk minden egyes ilyen apró hazugságra.

A hazugság, amit a legjobban utáltunk: a feltöltés, ami „sikerült"

A GeekBye biztonsági mentést tud készíteni a felvételeidről a Google Drive-ra. A v1-ben a Drive-hoz való kapcsolatot háttérrészletként kezeltük — ha működött, remek; ha nem, a hiba többnyire láthatatlan volt. Az alkalmazás továbbra is csatlakozottnak tűnt. Feltételezted, hogy a felvételeid biztonságban vannak. Néha nem voltak.

A v2 ezt őszinte kapcsolatállapotok köré építette újra. A Drive most már mindig néhány kifejezett, igaz állapot egyikében van — csatlakozva, újracsatlakozik, leválasztva —, és az alkalmazás minden állapotváltozást az egész felület felé sugároz abban a pillanatban, ahogy megtörténik. Amikor a kapcsolat elesik, egy globális újracsatlakozási sáv megmondja neked, mindenhol, világosan. Az alkalmazás többé nem tesz úgy, mintha egy feltöltés sikerült volna, amikor nem. Ha a biztonsági mentésed most nem történhet meg, azt most tudod meg — nem jövő héten, amikor keresni kezded a fájlt.

Mögötte ez egy kis architektúra, nem egy szlogen: egyetlen igazságforrás a kapcsolathoz, egy esemény, ami a felület minden részére szétterjed változáskor, és egy sáv, ami közvetlenül abból az állapotból olvas. Nincs olyan út, ahol a kapcsolat elesett, a felület pedig fentnek tűnik, mert mindkettő ugyanabból a tényből olvas.

Az elveszett felvétel hazugsága

A második nagy őszinteségi javítás a felvétel-helyreállítás volt. A valós idejű átiratnak élő kapcsolatra van szüksége. A v1-ben, ha ez a kapcsolat megbicsaklott egy munkamenet közepén — egy Wi-Fi-villanás, egy alagút, egy VPN-újracsatlakozás —, a kiesés alatti hang egyszerűen eltűnhetett. Az átiratban lyuk keletkezett, és semmi sem szólt róla.

A v2 megváltoztatta a megállapodást: a hang helyben megőrződik egy kapcsolati kiesés alatt, és utólag összeegyeztetődik. Amikor a kapcsolat megszakad, a GeekBye biztonságban tartja a hangot a gépeden; amikor visszatér, ez a pufferelt hang elküldődik és a megfelelő helyre varródik az átiratba. Rossz harminc másodpercnyi hálózat többé nem kerül harminc másodpercnyi értekezletbe. Ez az alap, amelyre a későbbi megbízhatósági kiadások közvetlenül építettek — az újracsatlakozási-és-pufferelési gépezet a miért áll le az AI jegyzetelőd rossz Wi-Fi-n írásban ugyanaz a gondolat, megedzve.

A felugró ablakok viharának hazugsága

Van egy finomabb tisztességtelenség abban, ahogy az alkalmazások jelentik a bajt: túljelentik. Egyetlen ingatag hálózati pillanat ötször is elsütheti ugyanazt a hibát, és hirtelen egy halom azonos piros toastod van, ami eltemeti az egyetlen üzenetet, ami számít. Ez sem őszinte — ez zaj, ami információnak tetteti magát.

Ezért a v2 hozzáadott kategóriakulcsú toast-fékezést és hibairányítást. A hibák aszerint csoportosulnak, hogy valójában mik, és minden kategória sebességkorlátozott, így egyetlen mögöttes probléma egy világos üzenetet produkál, nem pergőtüzet. Egy sebességkorlát-probléma egy sebességkorlát-üzenethez irányul; egy kapcsolati probléma egy kapcsolati üzenethez. Az alkalmazás megmondja neked, mi igaz, egyszer — ugyanaz a fegyelem, ami később megakadályozta, hogy egy 429 kijelentkezésnek álcázza magát a nap, amikor az alkalmazásunk DDoS-olta önmagát írásban.

A 206-os szám maga a lényeg

Őszinte állapotok, újracsatlakozási sáv, felvétel-helyreállítás, toast-irányítás — ez négy gondolat. A kiadás 206 commit volt. Hová ment a többi?

A nem látványos hosszú farokba, amelyet a „soha ne mutass hamis állapotot" valójában megkövetel. Minden helyet, ahol a régi felület kieshetett a valósággal való szinkronból, meg kellett találni és újrahuzalozni, hogy az igazságból olvasson egy elavult másolat helyett. Minden újracsatlakozási utat rá kellett venni, hogy a megosztott állapotot frissítse, ahelyett hogy helyben találgatna. Tucatnyi apró megbízhatósági javítás a felvételben, az átiratban és a feltöltésekben — mindegyik egy konkrét rést zárt be, ahol az alkalmazás helyesnek tűnhetett, miközben tévedett.

Ennyibe kerül egy valódi „második verzió", amikor a cél a bizalom, nem a funkciók. Nincs egyetlen főcím-commit. 206 apró van, és a kiadás csak azért érződik egyetlen dolognak — nyugalomnak —, mert mind a 206 ugyanabba az irányba húz.

A kiadás majdnem nem jelent meg

Íme a háborús történet, és jó, mert arról szól, hogyan hazudott a saját alkalmazásunk nekünk.

Amikor kiadást vágsz, egy verziónövelő szkript a projekt egészére rábélyegzi az új számot. A v2.0.0-nál frissítette az alkalmazás verzióját — de a package-lock.json, az npm pontos függőségi főkönyve, a régi verzión, 1.9.0-en maradt. Helyben minden rendben volt; senki sem telepíti újra a függőségeket csak azért, hogy buildeljen. De a CI npm ci-t futtat, és az npm ci egész dolga az, hogy megtagadja a továbbhaladást, ha a lockfile nem egyezik a manifesttel. Ez egy szigorúsági funkció — és pontosan azt tette, amit kellett, elbuktatva a buildet a legnagyobb kiadásnál, amit valaha vágtunk.

Aztán alatta felszínre került egy második, alattomosabb. Egy újabb npm lenyeste egy opcionális tranzitív függőséget — az encoding csomagot, amit a node-fetch húz magával — a lockfile-ból mint feleslegeset. Csakhogy a CI-nk tiszta telepítésének tényleg szüksége volt rá, így a telepítés úgy tört el, hogy annak semmi köze nem volt a kódunkhoz, és minden köze ahhoz, hogy a főkönyv finoman téves volt.

Mindkettő egysoros javítás volt: szinkronizáld újra a lockfile-t a valódi verzióra, állítsd vissza a lenyesett bejegyzést. Mindkettő egyben tökéletes, alázatra intő példája is pontosan annak, amiről a v2 szólt — egy állapot, amely azt állította, hogy igaz, és nem volt az. A lockfile-nak az kellene lennie, hogy őszinte feljegyzés arról, mitől függ az alkalmazás. Amikor eltért a valóságtól, a build pontosan azt tette, amit az alkalmazásunk most tesz a felhasználókért: megtagadta, hogy úgy tegyen, mintha minden rendben volna. Kiderül, hogy egy megbízhatósági kiadás szállítása végig megbízhatósági probléma.

Három dolog, amit a v2 tanított nekünk

1. A veszélyes hibák a csendesek. Egy összeomlás bejelenti magát. Egy hamis „csatlakozva", egy fantom sikeres feltöltés, egy láthatatlan lyukkal teli átirat — ezek éppen azért kerülnek bizalmadba, mert semmi sem tűnik rossznak. Vadászd a csendes hazugságokat.
2. Az őszinteség architektúra, nem üzenet. Nem csavarozhatod rá a „mondj igazat"-ot egy felületre sávként. A sávnak ugyanabból az egyetlen igazságforrásból kell olvasnia, mint minden másnak, különben egy újabb dologgá válik, ami téves lehet. Egy tény, szétterítve — soha nem két másolat, amely nem egyezhet.
3. Egy számhoz méltó második verzió többnyire láthatatlan. Ha a v2-d egy funkciólista, akkor egy v1.5 marketinggel. Egy valódi v2 az 206 commit, amelyet senki sem tud egyenként megmutatni, összeadódva egy termékké, amely egyszerűen abbahagyja, hogy hazudjon neked.

A GeekBye v2.0.0 az alap, amelyre minden azóta megjelent kiadás épített. Hogy mit hordoz ez az alap, lásd miért áll le az AI jegyzetelőd rossz Wi-Fi-n, a nap, amikor az alkalmazásunk DDoS-olta önmagát (v2.0.1) és élő átirat, amikor a tűzfal blokkolja a WebSocketeket (v2.0.8). A nyugalomért, amelynek szolgálatában mindez állt, mi újság a GeekBye v2-ben.