← Înapoi la „cum e construit”

Documentație în lucru: e verificată rând cu rând înainte de testarea deschisă. Nu lua nimic de-a gata.

Calitatea și felul în care lucrăm

Regulile care trăiesc în text se încalcă. Cele de aici opresc build-ul înainte să apuci să le încalci — un script care rulează în comanda obișnuită de verificare, pe laptop, înainte ca ceva să ajungă în CI. Mai toată disciplina de inginerie a proiectului ăstuia e un singur obicei: când un defect se poate repeta în tăcere, scrie regula în loc de notă.

Reguli care opresc build-ul

O regulă e o funcție dintr-un singur script. Primește un nume, un comentariu care argumentează de ce există, și un loc în verificarea pe care o rulează fiecare dezvoltator înainte să dea commit — nu un pas într-un fișier de CI, fiindcă o regulă care se declanșează doar la push e o regulă pe care o descoperi după ce ai scris deja codul greșit.

Genul de lucruri pe care le prind:

  • Capcane de execuție pe care testele nu le văd. Motorul de JavaScript de pe telefon n-are funcții pe care Node le are, așa că o suită de teste poate trece pe cod care ar crăpa pe telefon. O regulă le refuză din start în codul aplicației.
  • Convenții care se abătuseră de luni de zile. „Ecranele se compun din biblioteca de componente” era scris cu mult înainte să verifice ceva; până să apară o regulă, arborele de ecrane avea 32 de încălcări. A pornit cu clichetul fixat la 32, a fost dus la zero, iar lista de excepții a fost ștearsă.
  • Text netradus care ajunge la utilizator, inclusiv etichetele pentru cititorul de ecran — text pe care cineva îl citește chiar dacă nu-l vede nimeni.
  • Documente care n-au ce căuta în depozit, verificate față de ce ține git cu adevărat și nu față de ce pretinde un fișier de ignorare, fiindcă o ignorare e la un git add -f distanță de a fi ocolită, iar paguba cere rescrierea istoricului ca să fie dreasă.

O regulă vine cu propriul ei test. Cele mai noi își pun predicatul la treabă pe fixturi la fiecare rulare și pică zgomotos dacă nu mai prind lucrul pentru care există. O gardă pe care nimeni n-a văzut-o vreodată picând e o gardă despre care nimeni nu știe dacă mai merge, iar un predicat e exact genul de lucru care se oprește în tăcere din potrivit când cineva îl face mai frumos.

Numărul regulilor nu e publicat aici, intenționat. Se schimbă, iar un număr scris în text lângă o listă care crește e un fapt cu termen de expirare. Proiectul ăsta a făcut greșeala în propriile lui documente interne — un fișier a scris „nouă reguli” cu patru reguli mai mult decât trebuia — iar reparația a fost ștergerea numărului, nu întreținerea lui.

Clichetul de mărime

Fișierele sursă stau sub 500 de linii. Cele care erau deja peste atunci când a apărut regula sunt prinse la lungimea lor exactă într-o listă, iar garda pică dacă vreunul dintre ele crește. Pot doar să scadă, iar o intrare se șterge când fișierul ei coboară sub limită.

Mecanismul contează mai mult decât limita: un clichet transformă „ar trebui să facem curat pe aici” în „asta nu mai poate să se înrăutățească”, singura formă a acelei intenții care supraviețuiește unei săptămâni aglomerate. Și nu poate fi ocolit adăugând un fișier în listă, fiindcă exact asta există regula ca să împiedice.

Aceeași listă de fișiere e cea pe care formatatorul e pus s-o lase în pace, iar o regulă separată verifică faptul că cele două liste sunt identice — așa că reformatarea unui fișier prins nu-i poate schimba pe tăcute numărul de linii ca să rupă clichetul trei commit-uri mai târziu.

Suite care rulează pe o bază de date adevărată

Suitele de securitate pe rând se conectează la un Postgres adevărat, creează utilizatori adevărați și încearcă atacuri adevărate pe fiecare tabel legat de proprietar. Sunt descrise, cu propriul lor cod citat, pe Securitate.

Două lucruri despre ele stau aici, nu acolo. Nu pot fi îndreptate spre altceva decât o bază de date locală — fiecare client trece printr-o verificare care aruncă eroare dacă serverul nu e local, fiindcă o matrice distructivă cu doi utilizatori, îndreptată greșit, trebuie să pice zgomotos și nu să reușească în tăcere. Iar când sunt oprite, scriu o linie apăsată care spune asta; o suită sărită care arată ca o suită trecută e mai rea decât nicio suită.

Amândouă limbile, în pas

Româna e limba sursă, iar engleza o oglindește. O suită de paritate pică atunci când o cheie există într-una și nu în cealaltă, așa că o versiune tradusă pe jumătate nu poate să plece — iar picarea vine chiar în clipa în care se adaugă cheia, singura clipă în care e ieftin de reparat.

Pachetul de probe pe dispozitiv

Un set de scenarii scrise conduce aplicația adevărată pe un telefon adevărat. Rulează de mână, ceea ce e o slăbiciune și e numită ca atare mai jos.

Ce e mecanic e mai îngust și merită avut: fiecare identificator de element pe care îl apasă un scenariu trebuie să existe în codul aplicației, verificat la fiecare rulare. Asta închide un eșec pe care proiectul chiar l-a avut — un scenariu apăsa un identificator pe care o rescriere îl redenumise cu luni în urmă, iar pachetul pica de atunci fără ca cineva să știe, fiindcă nimic nu-l rula automat.

Lecția scrisă atunci e mai îngustă decât „rulează-l în CI”: o verificare care rulează doar când își amintește un om e o verificare care raportează starea lumii din ultima zi în care și-a amintit cineva.

Cum lucrăm

Două afirmații de aici sunt despre practică, nu despre cod. Niciuna nu poate fi verificată de un cititor din afară, și niciuna nu e îmbrăcată ca și cum ar putea.

Sprinturile se termină cu o retrospectivă scrisă, cu tot cu ce a ieșit prost. Una dintre ele scrie că un pachet de teste picase săptămâni la rând fără să observe nimeni, că un document intern susținea că o reparație e „dovedită pe dispozitiv” când aceeași pagină spunea că nu fusese cercetată, și că planul sprintului socotise un control drept neinteractiv când el se putea apăsa. Pentru asta e o retrospectivă, iar una lustruită nu ar folosi nimănui.

Versiunile sunt probate pe un telefon după o listă, în ordinea în care umbli prin aplicație.

Dacă obiceiul ține de fiecare dată nu e ceva ce un cititor din afară poate verifica. Aici ne crezi pe cuvânt, și e bine să știi unde anume.

Mai departe

  • Arhitectura — proiectul pe care îl apără regulile astea și deciziile care au ieșit prost.
  • Securitate — modelul de autorizare și suitele care îl dovedesc.