Perché era difficile da vedere
Il sito ha uno stato vuoto dichiarato: quando una lista non ha risultati, lo dice invece di mostrare una pagina rotta. È una scelta che rifaremmo. In questo caso, però, ha reso il difetto quasi invisibile: la pagina non sembrava guasta, sembrava vera. Diceva con calma che non c'era niente da mostrare, e chi la guardava concludeva che mancavano i contenuti.
C'è una lezione già qui. Uno stato vuoto onesto è un buon comportamento di prodotto e un pessimo strumento diagnostico. Se un archivio può essere vuoto per due motivi molto diversi, non c'è niente da pubblicare oppure non riusciamo a leggere quello che c'è, non si distinguono da fuori.
La catena di cause
Tre fatti veri, ognuno ragionevole da solo.
- Le pagine di archivio hanno i filtri, e i filtri vivono nei parametri dell'indirizzo. Una pagina che legge i parametri della richiesta non può essere calcolata una volta per tutte quando si costruisce il sito: va eseguita a ogni richiesta, su una funzione che parte, risponde e muore.
- I contenuti del sito sono file, non righe di un database. Il modulo che li legge apre la cartella dei contenuti a partire dalla posizione di lavoro del processo. In locale quella cartella c'è sempre, perché il processo gira dentro il progetto.
- Quando il progetto viene impacchettato per andare online, non viene copiato tutto: viene tracciato quello che il codice dimostra di usare. Una cartella letta a runtime, il cui percorso viene composto mentre il programma gira, non è dimostrabile in anticipo. Quindi non veniva copiata.
Sommando: la pagina partiva, chiedeva la lista dei contenuti, la cartella dei contenuti non era lì, la lista tornava vuota, la pagina mostrava con garbo il suo stato vuoto. Nessuno dei tre passaggi è un errore. Il difetto sta nella loro combinazione, e nessuno dei tre file coinvolti, presi uno per uno, sembrava sospetto.
La correzione
Una riga di configurazione che dichiara in modo esplicito quello che il codice non può dimostrare: la cartella dei contenuti va inclusa nel pacchetto per tutte le rotte.
La verifica, invece, è la parte che conta e che spesso si salta: non basta che riparta in sviluppo. La build di produzione va costruita e servita, e l'archivio va aperto lì. Sviluppo e produzione, in questo caso, non sono lo stesso programma con un interruttore diverso: sono due modi diversi di mettere insieme i file.
Certi bug esistono solo dove non stai guardando
Questa è la parte trasferibile, e vale ben oltre il caso specifico.
Un difetto che dipende dall'ambiente non si trova con il ragionamento. Il codice è corretto, i test passano, la revisione non ha niente da segnalare, perché il codice davvero non ha niente che non va. Quello che manca è un pezzo di contesto che in un ambiente c'è e nell'altro no: un file, una variabile, un permesso, il modo in cui il sistema operativo confronta due nomi di file che sembrano identici.
Nello stesso periodo ci è capitato l'esempio da manuale: l'immagine di un capitolo non veniva servita, ma solo online. Il nome del file conteneva una lettera accentata scritta in una forma di codifica che il computer su cui era stata creata e il server che doveva servirla trattavano come due nomi diversi. Sul portatile si vedeva, sul server era un errore quattrocentoquattro. Nessuno può trovare una cosa così leggendo il codice.
Cosa abbiamo cambiato nel metodo
Tre regole, tutte noiose, tutte utili.
- Le pagine più importanti si guardano sulla build di produzione, non in sviluppo. Almeno una volta per rilascio, con i propri occhi. Non è un test automatico, è un rito.
- Uno stato vuoto in produzione è un incidente finché non è dimostrato il contrario. Se una lista che dovrebbe avere contenuti risponde zero, la prima ipotesi non è che manchino i contenuti.
- Le dipendenze invisibili si scrivono. Le cose che il sito legge da fuori del proprio codice, cartelle, nomi di file, variabili d'ambiente, non le ricorda nessuno dopo sei mesi. Nel nostro repository quella riga di configurazione ha un commento accanto che spiega perché esiste e cosa succede se qualcuno la toglie. È la forma più economica di manutenzione che conosciamo.
