Reed ir analizė, paliekanti įrašus

Reed parsavimą traktuoja kaip tai, ką CI, redaktoriai, auditoriai ir leidybos grandinės gali patikrinti vėliau.

Reed ir analizė, paliekanti įrašus

Analizatorius paprastai praryja įrodymus

Kiekviena programinės įrangos organizacija jau pasikliauja analizatoriais. Kompiliatoriai analizuoja. Linteriai analizuoja. Redaktoriai analizuoja. Statinės analizės įrankiai analizuoja. Formatuotojai analizuoja. Kūrimo sistemos analizuoja konfigūracijas, manifestus, užrakinimo failus ir šaltinio medžius, kol patalpoje ima dvokti reguliariosiomis išraiškomis ir gailesčiu.

Vis dėlto dauguma komandų analizavimą laiko vienkartiniu tarpiniu žingsniu. Procesas nuskaito failą, atmintyje sukuria AST arba analizės medį, jį panaudoja ir leidžia jam išnykti. Jei vėliau kas nors paklausia, ar dvejetainis failas buvo sukurtas iš patvirtinto šaltinio, ar pasikeitė priklausomybė, ar leidimas apėmė konkrečią funkciją, ar peržiūra matė tą patį medį kaip CI, atsakymas dažnai tampa socialiniu atsakymu. Pasitikėkite kūrimo sistema. Pasitikėkite žurnalais. Pasitikėkite įrankiu. Pasitikėkite žmogumi, kuris dabar atostogauja.

Rimtoms tiekimo grandinėms to nepakanka. Šaltinio kodas yra ne tik tekstas. Tai įrodymai. To teksto forma svarbi. Jame esantys ryšiai svarbūs. Būdas, kuriuo jis buvo analizuojamas, svarbus. Jei ta struktūra egzistuoja tik išnykusiame procese, organizacija išmetė tai, ko jai vėliau reikės įrodymams.

Būtent šiai spragai ir skirtas Reed. Reed puslapyje jis pristatomas kaip atvirojo kodo analizatorius ir kilmės sluoksnis: GLL analizavimas, SPPF struktūra, Merkle medžio tapatybė, BLAKE3 sertifikatų šaknys, RQL užklausos, CLI naudojimas, redaktoriaus integracija, C ABI, WASM ir Python sąsajos. Esmė ne tik tai, kad Reed analizuoja. Esmė ta, kad analizavimas palieka nešiojamą kvitą.

Reed analizės medį traktuoja kaip objektą, kurį galima adresuoti, įtvirtinti ir patikrinti vėliau, o ne kaip laikiną objektą, kuris miršta kartu su procesu.

Tai nedidelis žodžių pakeitimas, bet didelis požiūrio pokytis. Analizatorius, grąžinantis naudingą medį, yra kūrėjo įrankis. Analizatorius, grąžinantis naudingą medį su stabilia šaknimi, tampa kūrimo infrastruktūra. Dabar CI gali paskelbti šaknį. SBOM įrankiai gali ją užfiksuoti. Leidimo procesas gali ją įtvirtinti. Recenzentas gali ją palyginti. Auditorius gali užduoti klausimą nereikalaudamas, kad visi po teatrališku apšvietimu atkurtų visatą iš naujo.

Kūrimo kilmė prasideda iki dvejetainio failo

Apie kūrimo kilmę dažnai kalbama vamzdyno pabaigoje: pasirašytas artefaktas, SBOM, leidimo pastaba, diegimo patvirtinimas, galbūt skydelis, kuris sako „atitinka reikalavimus“ tokiu pasitikėjimu, kokiu vyras parduoda stogo izoliaciją. Tie elementai svarbūs, bet jie pavėluoti. Iki tol šaltinis jau praėjo analizavimą, kompiliavimą, transformavimą, sujungimą ir pakavimą.

Jei šaltinio struktūra niekada nebuvo užfiksuota, leidimo kvitas turi skylę viduryje. Žinote, kad artefaktas buvo pasirašytas. Galbūt žinote įsipareigojimo maišą. Bet ar galite parodyti išanalizuotą šaltinio formą, kurią matė analizė? Ar galite įrodyti, kad sugeneruotas dvejetainis failas atitinka išanalizuotą medį su ta pačia šaknimi? Ar galutinis vartotojas gali patikrinti, ar įtraukta priklausomybė tyliai nepasikeitė turėdama tą patį failo pavadinimą?

Naudingas Reed pažadas yra įdėti patikrinamą objektą į analizavimo sluoksnį. BLAKE3 šaknis nėra rinkodaros poezija. Tai kompaktiška išanalizuotos struktūros nuoroda. Sertifikatas nėra gražus paaiškinimas. Tai dalykas, kurį gali nešiotis kiti įrankiai. Taip analizavimas tampa kilmės dalimi, o ne miglotu žingsniu tarp git ir dvejetainio failo.

Tai svarbiausia tada, kai ateina nuobodūs klausimai. Ar šis dvejetainis failas buvo sukurtas iš patvirtinto šaltinio? Ar peržiūrėtas kodas ir diegiamas kodas turėjo tą pačią išanalizuotą struktūrą? Ar priklausomybė pasikeitė po patvirtinimo? Kuris failas įvedė mazgą, kuris vėliau tapo politikos problema? Šie klausimai nėra egzotiški. Tai pagrindiniai programinės įrangos atskaitomybės klausimai. Mes tiesiog apsimetame, kad jie reti, nes įrankiai daro juos erzinančius.

Vienas pakeitimas neturi virsti siena

Šaltinio peržiūra subyra, kai nedideli pakeitimai sukuria didelius neįskaitomus skirtumus. Kiekvienas tai žino. Vienos eilutės pakeitimas priverčia sugeneruotą išvestį persitvarkyti. Formatuotojas pakeičia aplinkinį tekstą. Parseris ar analizės įrankis praneša, kad pusė medžio yra nauja. Peržiūra virsta siena, o žmonės daro tai, ką žmonės daro su triukšmo sienomis: jie peržvelgia, atsidūsta ir patvirtina daugiau, nei turėtų.

„Reed“ turinio adresavimo laikysena suteikia geresnį tikslą. Jei nepakeisti mazgai išlaiko savo tapatybę, nedidelis pakeitimas gali likti nedideliu pakeitimu struktūroje. Aplinkinis medis neturi tapti įtartinas vien todėl, kad viena šaka pajudėjo. Tai ne tik našumo istorija. Tai peržiūros istorija. Tai reiškia, kad žmogus gali susitelkti į tai, kas pasikeitė, užuot derėjęsis su įrankiu, kuris mano, kad viskas yra nauja kiekvieną antradienį.

Gera kilmė mažina triukšmą. Vertingas skirtumas yra ta dalis, kuri iš tikrųjų pasikeitė, o ne kiekviena šaka, kuri atsitiktinai buvo šalia.

Čia analizė tampa operacine. Įprastas parseris gali būti teisingas ir vis tiek operaciškai nepatogus. Jei jis sukuria struktūrą ir išmeta šaknį, vėlesni įrankiai turi iš naujo analizuoti, iš naujo pasitikėti arba iš naujo parengti viską. Jei jis įrašo stabilų sertifikato šaknį, sistema gauna mažesnį objektą palyginimui. Mažesnius objektus lengviau automatizuoti. Lengvesnė automatizacija reiškia mažiau ritualų. Mažiau ritualų reiškia mažiau penktadienio popiečio patvirtinimų, atliekamų viena akimi į traukinį namo.

Tai nėra įspūdinga. Tai labai naudinga. Pramonė dažnai bando išspręsti pasitikėjimą prietaisų skydeliais, kai pirmiausia turėtų padaryti pagrindinį objektą pakankamai stabilų palyginimui.

Kalbos keistenybės yra ten, kur parseriai mokosi nuolankumo

Analizė atrodo švari diagramose. Žetonai įeina. Medžiai išeina. Tada ateina tikra kalba ir atsineša įtraukas, neapdorotas eilutes, įdėtus komentarus, heredoc, nowdoc, regex literalus, kurie atrodo kaip dalyba, interpoliaciją, shell citavimą, XML kraštinius atvejus ir konfigūracijos formatus, kurie, matyt, buvo sukurti per nesutarimą.

„Reed“ skaitytuvo medžiaga įdomi, nes šias keistenybes traktuoja kaip aiškius inžinerinius rūpesčius. Įtraukos stebimos. Heredoc ir nowdoc atvejai egzistuoja. Įdėti blokiniai komentarai modeliuojami. „JavaScript“ ir „TypeScript“ regex ir dalybos skirtumas priklauso nuo ankstesnio žetono konteksto. Neapdorotos eilutės ir interpoliacija turi savo tvarkymą. Būtent šiame sluoksnyje apsimetimas tampa brangus.

AI sistema, kuri priklauso nuo kodo supratimo, negali traktuoti analizės kaip pojūčių pratimo. Saugumo skaitytuvas negali praleisti bloko, nes kalba naudojo keistą eilutės formą. Dokumentacijos ištraukėjas negali tyliai praryti heredoc ir baigti dienos. Kodo paieškos įrankis negali elgtis skirtingai redaktoriuje, CI ir Python scenarijuje, nes kiekviena integracija naudojo skirtingą parserį su šiek tiek skirtingomis interpretacijomis.

Šios nemalonios sintaksės smulkmenos nėra šalutinės užduotys. Jos yra vieta, kur kodo supratimas tampa aiškus arba pradeda mandagiai meluoti.

Eksplicitiniai skaitytuvai yra svarbūs ne tik dėl teisingumo. Jie svarbūs todėl, kad taisyklės tampa pakankamai matomos peržiūrai. Jei skaitytuvas žino, kodėl pasvirasis brūkšnys yra reguliarioji išraiška, o ne dalybos ženklas, šį faktą galima patikrinti. Jei įtrauka sukuria INDENT ir DEDENT žetonus, apie tokį elgesį galima samprotauti. Jei įdėtieji komentarai palaikomi iki neriboto gylio, yra taisyklė, o ne gūžtelėjimas pečiais. Gūžtelėjimas pečiais nėra analizatoriaus strategija, nors daugelis kodų bazių tai bandė.

Vienam varikliui reikia daug durų

Analizatoriaus infrastruktūra tampa keista, kai kiekviena sąsaja įgyja savo versiją. CLI turi vieną interpretaciją. Redaktorius turi kitą. CI scenarijus iškviečia dar ką nors kita. Python darbo eiga kreipiasi į dvejetainį failą. Naršyklės įrankis naudoja atskirą WASM versiją. Tada kas nors paklausia, kodėl diagnostika skiriasi tarp vietinės plėtros ir vykdymo grandinės. Atsakymas paprastai yra bendras dokumentas, kurio niekas nežino.

Reed puslapyje pateikiamas nuoseklesnis sąsajų modelis: pagrindinis analizės variklis, CLI, skirta analizei, užklausoms ir sertifikatų darbui, Language Server Protocol integracija diagnostikai ir naršymui, stabilios C sąsajos ne-Rust platformoms, WASM ir Python. Vertė nėra ta, kad kiekviena sąsaja egzistuoja dėl savęs. Vertė ta, kad jos gali kalbėti per tą pačią analizatoriaus sutartį.

Sąsaja turėtų keistis vartotojui, o ne prasmė. CLI, redaktorius, sąsajos ir naršyklės įrankiai turėtų rodyti į tą pačią analizatoriaus sutartį.

Būtent ši sutartis leidžia Reed derėti su likusia technologijų krūvos dalimi. Spindle gali valdyti žinias tik tada, kai šaltinio atomai yra pakankamai stabilūs, kad jais būtų galima pasitikėti. AION ir Trace gali perduoti įrodymus tik tada, kai ankstesnių artefaktų tapatybės yra apibrėžtos. Ledger gali užfiksuoti įvykį, bet įvykis yra stipresnis, kai jis nurodo analizės šaknį, o ne miglotą failo kelią. Fabric gali parodyti šaltiniu pagrįstą atsakymą, bet šaltiniu pagrįstas atsakymas yra mažiau įspūdingas, kai šaltinio medžio forma keičiasi priklausomai nuo to, kuris įrankis į jį žiūrėjo.

Reed nepakeičia šių sluoksnių. Jis suteikia jiems geresnį objektą. Tai yra teisingas darbo pasidalijimas. Įrankiai tampa nepatikimi, kai bando būti visa civilizacija. Reed analizuoja, maišo, sertifikuoja ir atveria sąsajas. To pakanka.

Našumo skaičiai yra naudingi, bet ne esmė

Reed puslapyje pateikiamos konkrečios etaloninių testų kategorijos: SIMD struktūrinis nuskaitymas kelių gigabaitų per sekundę diapazone, lentelėmis pagrįsta SLR analizė JSON, TOML, XML ir Dockerfile formatams bei lėtesnė GLL analizė Rust kalbai su visišku CFG ir dviprasmybių palaikymu. Šie skaičiai naudingi, nes nustato lūkesčius. Struktūrinis nuskaitymas nėra tas pats, kas kalbos analizatorius, gebantis atpažinti dviprasmybes. Jei kas nors juos lygina taip, lyg jie būtų tas pats, tas asmuo arba klysta, arba kažką parduoda. Kartais abu.

Stipresnė istorija nėra vienas herojiškas skaičius. Tai darbo forma. Naudokite greitus struktūrinius kelius ten, kur formatas tai leidžia. Naudokite sudėtingesnę analizę ten, kur kalba to reikalauja. Išlaikykite sertifikato šaknį. Padarykite rezultatą užklausiamą. Leiskite CI ir audito įrankiams nešti kompaktišką faktą, o ne pasakojimą apie laužą.

Tai taip pat skirtumas tarp etaloninių testų teatro ir inžinerijos. Etaloninis testas turėtų padėti pasirinkti ir suderinti įrankį. Jis neturėtų tapti įrankio tapatybe. Reed įdomus todėl, kad jo įrodymų pozicija išlieka net pasikeitus darbo krūviui. JSON ir Rust nereikalauja tos pačios analizatoriaus strategijos. Tačiau jie reikalauja tokio pat rimtumo kvitų atžvilgiu.

Kur Reed tinka

Reed turi būti prieš kodo intelektą, prieš kūrimo įrodymus, prieš šaltiniu pagrįstą dirbtinį intelektą, dirbantį su kodu, ir prieš bet kokį auditą, kuris nori klausti apie tai, kas pasikeitė. Jis yra toje vietoje, kur tekstas tampa struktūra. Ši vieta yra svarbesnė, nei atrodo, nes nuo jos priklauso kiekvienas vėlesnis teiginys apie kodą.

Inžinerijos komandoms tiesioginė nauda yra praktinė. Išanalizuokite vieną kartą pagal žinomą sutartį. Klauskite struktūros, o ne naršykite grep košę. Skelbkite šaknis CI. Įtraukite sertifikatus į leidimo įrodymus. Laikykite redaktorių, CLI ir automatizavimo sąsajas suderintas. Kai peržiūroje klausiama, kas pasikeitė, atsakykite struktūrą suprantančiu kvitu, o ne ekrano kopija ar įsitikinusia pastraipa biliete.

Dirbtinio intelekto sistemoms Reed yra apsauga nuo labai šiuolaikiškos nesąmonės: kodo supratimo, kuris negali atkartoti, kaip jis suprato kodą. Jei DI asistentas paaiškina funkciją, siūlo refaktorių arba patvirtina politikos savybę, už to atsakymo esanti šaltinio struktūra turėtų būti pakankamai stabili, kad ją būtų galima patikrinti. Priešingu atveju asistentas tiesiog spėja iš arbatžolių su sintaksės paryškinimu.

Pamoka

Reed pamoka paprasta: analizė nėra vienkartinė įžanga. Ji yra įrodymų grandinės dalis. Jei analizatorius išmeta naudingą struktūrą, žemesnio lygio sistemos paveldi pasitikėjimo problemą ir tada mėnesius ją puošia.

Geras analizės sluoksnis turėtų palikti kvitą. Jis turėtų aiškiai tvarkyti kalbos ypatybes. Jis turėtų išlaikyti tapatybę stabilią per nedidelius pakeitimus. Jis turėtų atskleisti tą pačią reikšmę per CLI, redaktorių, ABI, WASM ir scenarijus. Jis turėtų leisti kūrimo, audito ar DI darbo eigai nukreipti į kažką konkretesnio nei pasitikėkite mumis, medis buvo gerai, kai žiūrėjome.

Tai naudinga Reed forma: ne analizatoriaus blizgesys, ne sintaksės turizmas, ne dar vienas įrankis, kuris sukuria JSON krūvą ir vadina tai įžvalga. Analizės branduolys, paverčiantis šaltinį patikrinama struktūra, su šaknimis ir sertifikatais, kuriuos kitos sistemos gali nešiotis. Sausas darbas, taip. Svarbus darbas paprastai toks ir yra. Blizganti dalis ateina vėliau, kai kažkas sugenda ir jūs tikrai galite įrodyti kur.