Fondamenta: leggere il registro di verifica di una build

Tre settimane fa ho realizzato un widget di prenotazione per un'amica che gestisce uno studio di yoga — una chat, un piano che ho approvato in fretta perché ero occupato con altro, un'esecuzione, e poi una scheda versione con un segno di spunta verde che ho guardato di sfuggita e su cui sono passato oltre. Martedì mi ha scritto chiedendomi se poteva far puntare il sito di un secondo studio alla stessa build. Prima di dire di sì sono tornato a vedere cosa avesse effettivamente significato "verificato" tre settimane prima, ed è lì che ho davvero letto uno di questi verbali per la prima volta invece di limitarmi a fidarmi del segno di spunta.

Si trova proprio sulla scheda della versione, accanto all'anteprima e alle azioni sul codice — nello stesso posto in cui andresti per ripubblicare o tornare a una versione precedente. La prima cosa che ho notato: è specifico per quella singola versione, non per l'intera conversazione. Avevo iterato su questa build cinque volte inseguendo un selettore di date rotto, e mi aspettavo un po' che il verbale mi raccontasse la storia di tutto il botta e risposta. Non lo fa. Il verbale della versione 4 descrive solo la versione 4. Non ha memoria del fatto che la versione 2 sia stata pubblicata con un modulo di login che falliva silenziosamente, e non mi dirà che la versione 5 ha risolto silenziosamente qualcosa che la versione 3 aveva rotto. Ogni verbale è un'istantanea, non un diff né un changelog — se voglio la cronologia di cosa è cambiato rilascio dopo rilascio, quella è una vista completamente diversa. Questa risponde solo a "questa versione va bene".

Scorrendo verso il basso, il verbale si suddivide in sei righe:

Tutti e sei erano verdi, e il mio primo istinto è stato lo stesso istinto sbagliato che immagino abbiano la maggior parte delle persone: la sicurezza è passata, quindi è sicuro; l'accessibilità è passata, quindi è accessibile. Nessuna delle due letture regge alla prova di ciò che i controlli fanno davvero. Il passaggio sulla sicurezza significa che le cose superficiali — una concatenazione di stringhe in una query, una chiave API esposta nel bundle client, un eval su qualcosa digitato da un utente — non sono emerse. Non è una giornata con un penetration tester. Lo studio di yoga della mia amica non accetta pagamenti tramite questo widget, solo nomi e fasce orarie, quindi il livello base andava bene per lei. Se fosse stato un flusso di checkout, avrei voluto qualcosa di più di una semplice base.

L'accessibilità è la riga che mi ha effettivamente fatto fermare a cercare qualcosa, perché "passaggio con axe" suona esaustivo e non lo è. Axe — il motore automatico che gira sotto il cofano — intercetta in modo affidabile qualcosa come un terzo o la metà dei criteri di successo WCAG: testo alternativo mancante, rapporti di contrasto scadenti, campi modulo senza etichetta, uso evidentemente scorretto di ARIA. Non può dirti se il menu a tendina del selettore di date personalizzato che avevo chiesto sia utilizzabile con uno screen reader, se tabbando attraverso il flusso di prenotazione multi-passaggio il focus finisca in un punto sensato, o se lo stato "confermato" contro "in attesa" che avevo colorato di verde e giallo sia un problema per chi ha daltonismo rosso-verde. Per quello serve una persona che percorra la build con gli stessi strumenti su cui fanno affidamento gli utenti con disabilità. Axe è un segnale reale, non è niente — è il livello del correttore ortografico dell'accessibilità, non l'editor.

La conformità è la riga che ho quasi saltato, perché suona burocratica — "contiene ciò che il piano prometteva" — finché non mi sono ricordato che il piano che avevo approvato era stato scritto mentre ero distratto, e onestamente non ricordavo se avessi chiesto conferme via email o solo via SMS. Questo è il livello che controlla la build rispetto al piano, non rispetto alla mia intenzione reale, ed è passato, il che mi ha detto che la build corrispondeva a ciò a cui avevo detto sì, non necessariamente a ciò che intendevo. Ho sentito di build che erano funzionalmente solide e sicure ma che sono comunque fallite a questo livello perché una funzionalità è stata silenziosamente eliminata sotto pressione di tempo. È il livello che mantiene una build onesta rispetto alla conversazione che l'ha prodotta, anche quando la conversazione stessa è stata un po' sciatta.

Sotto le sei righe c'era un elenco più lungo, diviso in due categorie, ed è lì che ho passato più tempo. Gli elementi da correggere obbligatoriamente non sono cose attualmente sbagliate nella build — sono ricevute. Una riga diceva che il livello di revisione aveva segnalato un caso in cui una stringa di data veniva interpolata direttamente in una query, ed era già stata corretta prima che questa versione fosse contrassegnata come completa. Non stavo guardando una ferita aperta; stavo guardando una cicatrice. Questa distinzione conta, perché se leggi una voce da correggere obbligatoriamente come un avviso attivo, finirai per preoccuparti di qualcosa che è già stato risolto.

L'elenco degli avvisi era più lungo, ed era per lo più composto da cose che avrei detto io stesso se stessi revisionando il codice di un collega senza voler bloccare il merge: "considera di estrarre il blocco ripetuto di rendering delle fasce orarie in un componente condiviso", "questo endpoint non ha limitazione della frequenza delle richieste, il che va bene per uno strumento di prenotazione interno ma vale la pena riconsiderarlo se diventa pubblico". Nulla in quell'elenco era un difetto. Erano valutazioni fatte da un verificatore avendo a disposizione solo il piano e il codice, e per uno scheduler interno di uno studio di yoga, ognuna di quelle valutazioni ricadeva dal lato ragionevole. Se lo studio della mia amica fosse stato una catena in franchising con il widget incorporato in cinquanta pagine di sedi diverse, avrei voluto contestare quella sulla limitazione della frequenza — la classificazione dipende da un contesto che il verificatore può solo intuire, e quando un'intuizione ti sembra sbagliata, la mossa giusta è dirlo in chat, non assumere che l'etichetta sia definitiva.

Ciò che mi ha colpito, guardando un elenco di avvisi di dimensioni discrete accanto a una colonna degli elementi obbligatori pulita, è che avrei quasi letto la sua lunghezza come una cattiva notizia. Non lo è. Una build con zero note di avviso ha ottenuto un controllo superficiale oppure è stata fortunata; una build con una pila di elementi "considera" e nulla in sospeso nella colonna degli elementi obbligatori è una che è stata effettivamente esaminata con attenzione. La colonna degli avvisi è ciò che dovrebbe rimanere una volta eliminati i problemi reali.

L'altra cosa che mi sono imposto di fare, dato che questo verbale era vecchio di tre settimane, è stato controllare quali livelli fossero effettivamente stati eseguiti prima di fidarmi dei verdetti. Erano presenti tutti e sei qui, ma da allora ho visto una build in cui l'accessibilità era semplicemente assente dall'elenco invece di essere contrassegnata come superata o non superata — non è la stessa cosa di essere saltata perché non importante, è un segnale che il controllo non è stato eseguito per quel particolare tipo di sito o configurazione di flag, e leggere l'assenza come un tacito successo è esattamente l'errore che questo formato invita a fare se lo si scorre distrattamente.

Niente di tutto ciò mi ha detto se il flusso di prenotazione dello studio di yoga converta davvero, se le persone lo abbandonino al passaggio della scelta della fascia oraria, o se l'idea stessa di un widget personalizzato invece di rimandare semplicemente a Calendly fosse stata la scelta giusta fin dall'inizio. La verifica dimostra che una build funziona come promesso, non che la promessa fosse quella giusta da fare — sono domande separate, e ho visto build superare ogni livello senza intoppi e comunque fallire con utenti reali perché "funziona correttamente" e "risolve il problema giusto" non si sovrappongono quanto si vorrebbe sperare. La metà di tutto questo che risponde davvero alla seconda domanda è il ciclo di misurazione, e i due sono pensati per essere letti insieme. Un verbale di verifica pulito su una funzionalità che nessuno usa per prenotare resta comunque una funzionalità che nessuno usa per prenotare.