FlowSharp

Dichiarato, ma non applicato

Una revisione di FlowSharp scopre differenze tra regole dichiarate e comportamento reale: confronti tra dati, permessi e assegnazioni da riconciliare.

FlowSharp: Dichiarato, ma non applicato. Illustrazione editoriale del Diario.

Ci sono errori che si fanno vedere subito. Quelli di questa settimana erano più scomodi: l’interfaccia dichiarava una regola e il motore, in alcuni casi, si comportava diversamente.

Una condizione come «importo maggiore o uguale a cento» sembra inequivocabile. Se però il valore arriva come testo e il confronto si aspetta un numero, l’esito può essere sbagliato senza che qualcuno riceva un errore comprensibile.

La regola esiste. La protezione che credi di avere, no.

Controllare quello che avevo già dato per fatto

Ho ripreso il motore delle regole, lavorando sui confronti e sulla gestione dei tipi di dato.

È una revisione che richiede pazienza. Non basta correggere l’esempio che ha fatto emergere il problema: bisogna vedere dove viene usato lo stesso criterio e quali altri comportamenti dipendono da lui.

Il lavoro è stato organizzato in otto ondate, con un triage di settantadue schede di bug. Mi è servito per evitare di inseguire la segnalazione più recente e perdere il filo di quelle già aperte.

Non tutte le schede avevano lo stesso peso. Ho cercato di dare priorità a ciò che poteva far credere a una persona di avere un controllo che in realtà non c’era.

I permessi e le responsabilità devono seguire il percorso

Ho verificato anche i ruoli in sola lettura e la riconciliazione degli assegnatari.

Se una pratica cambia contesto, non posso limitarmi a conservare il nome di chi c’era prima. Devo controllare se quell’assegnazione abbia ancora senso e se le autorizzazioni corrispondano alla situazione attuale.

Lo stesso vale per la documentazione: dire che una funzione fa qualcosa è utile soltanto se quel comportamento è provato e se la spiegazione resta allineata.

Una settimana di correzioni

I commit sono duecentosettantasette. Non c’è una novità sola che rappresenti questi giorni.

Mi resta soprattutto il fastidio di scoprire cose che credevo già sistemate. Provo a usarlo bene, senza trasformarlo né in allarme continuo né in una ragione per minimizzare.

FlowSharp deve aiutare a rendere affidabili i processi. Vale la pena cominciare dalle regole che applica a se stesso, anche quando il risultato del lavoro è semplicemente che una promessa già fatta comincia a essere rispettata.

Argomentibuild-in-publicflowsharpqualitadocumentazioneestate