Sviluppo casereccio: un piccolo bestiario
Premessa
In un'azienda, un programmatore ha scritto un po' per volta una webapp per uso interno, diventata rapidamente utilissima al punto da far domandare a un amministratore se fosse in condizioni di poter essere venduta.
E' una buona idea? Risolvere problemi oggettivi è encomiabile ma farlo in un contesto protetto è spesso ben diverso dall'esser pronti per andare in produzione.
Ci sono intere biblioteche sull'ingegneria del software: nel suo piccolo, questo articolo elencherà alcuni problemi che se la vostra pur ottima webapp sviluppata internamente dovesse avere, sarebbe meglio correggere prima di lasciarla alla mercè del mondo.
Gravi e oggettivi
Questi problemi sono certamente da risolvere, indipendentemente dalle opinioni tecniche personali di ciascuno.
Fotografia di Aaron Ang / Unsplash
- Schema validation assenti o incompleti: potenzialmente, i dati inseriti possono essere inconsistenti o creare problemi di sicurezza. La gravità non è tanto nel non aver aggiunto la validazione degli endpoint REST (e/o delle relative chiamate client) quanto la possibilità di non poterli inserire così agevolmente se il sistema/framework sviluppato e utilizzato non separa chiaramente le fasi nel ciclo di vita della richiesta.
- Risposte servite al client contenti informazioni di servizio o di debug: questo può vagamente essere accettabile in un contensto interno ma al di fuori di questa stretta cerchia di utenti, perché fornire sempre delle informazioni che potrebbero essere utilizzate contro l'applicativo? Il debug può capitare ma si possono restituire queste informazioni ulteriori in un ambiente di sviluppo (e solo durante quella fase) attivando opportunamente questa funzione.
- Nessuna autenticazione e/o autorizzazione integrata: come per la validazione dell'input, escludendo alcune nicchie applicative, è difficile pensare a un programma che non richieda una qualche profilazione dell'utente per poter accedere a diverse sezioni e, come nel caso precedente, se non si è scelto qualcosa fin da subito che sia in grado di gestire questi aspetti, inserirlo a posteriori senza sporcare il codice potrebbe essere molto complesso e dispendioso.
- Niente transaction: la coerenza dei dati e la loro protezione al variare degli stati (eccezioni e imprevisti inclusi) dovrebbe essere tra le prime preoccupazioni in fase di progettazione; nel caso di RDBMS, il non poter effettuare un rollback di protezione in modalità totalmente gestita può essere un serio problema.
- Sviluppare su software obsoleto: utilizzare una versione di un linguaggio di programmazione e/o delle librerie dichiarate deprecated è un problema di sicurezza che, a differenza di un uso in una rete locale, non ci si può permettere il lusso di ignorare. “Don't let your software rot”: una frase che lessi oltre vent'anni fa su di una celebre rivista di automazione industriale ed è certo una massima sempre valida, in ogni campo.
- Scarse prestazioni: se i pur pochi utenti locali, anche se soddisdatti a livello funzionale, osservano dei discreti tempi d'attesa per ottenere i dati, come si può pensare che il software sia in grado di reggere in uno scenario più generale? La scalabilità non si ottiene aumentando “il ferro”.
- Assenza di scalabilità “by design”: immaginare di avere a completa disposizione l'intero sistema operativo, come si faceva quindici o venti anni fa, senza separazione dei livelli, è un buon modo per non sostenere né il traffico né i tempi di attesa richiesti dagli utenti di oggi; se non avete mai sentito parlare di: progettazione 12 factors app (o della sua evoluzione derivata dal lavoro diciamo pionieristico di Heroku), di Docker, di Kubernutes, di microservizi, di AWS Lambda, di OpenFaaS o di programmazione serverless in generale… beh forse allora è arrivato il momento di prendersi una pausa dal lavoro quotidiano e di studiare che cosa è successo nel 21esimo secolo.
- Nessun audit di sicurezza: se siete in un ambiente protetto, se ne può forse ignorare l'importanza ma là fuori ci sono persone (e programmi in esecuzione) che tenteranno di distruggere il vostro applicativo, per quanto piccolo e poco pubblicizzabile possa esserne il risultato. Vale la pena correre il rischio? Come vi potreste giustificare con il management? Un audit di sicurezza sarebbe una buona idea e, naturalmente, i relativi ricircoli di correzione sui problemi emersi.
- Assenza di qualsiasi tipo di test: qui non credo ci sia molto da aggiungere ma è uno scenario molto diffuso.
- Nessuna documentazione: né REST/OpenAPI (YAML), né dell'architettura del sistema client e/o server, nessun tutorial... solo la conoscenza di una persona o una equivalente “tradizione orale”.
Gravi e soggettivi
Questi problemi sono per me quasi altrettanto gravi quanto i precedenti ma li ho classificati come soggettivi perché, se la progettazione è opportuna, possono non essere un problema, almeno secondo alcuni. 😜
Photo by The Roaming Platypus / Unsplash
- Mancanza di integrità referenziale: un approccio al RDBMS di questo tipo sposta la gestione di molta logica verso il programmatore e non la sola gestione degli errori che si avrebbe in caso contrario.
- Uso di un framework non pubblico, magari con l'aggravante di essere stato sviluppato in house e/o da un lone programmer: un prodotto simile lo conosceranno in pochi (pochi sapranno mantenerlo e correggerne gli errori) e molto difficilmente un programmatore vorrà impararlo perché non è per lui una “moneta”, non può essere scambiato con altri in una professione totalmente culturale come la nostra, nella quale peraltro il passaggio tra progetti e aziende diverse è molto frequente. Inoltre c'è il rischio che l'autore del prodotto interno diventi un “guardiano della codebase”, per non parlare dell'impossibilità di avere gli stessi standard di qualità, di sicurezza, di estendibilità di un prodotto di terze parti, meglio se software libero di grande importanza e diffusione, con abbondante documentazione e uno sviluppo ben sostenuto dalla community e/o da una società di rilevo.
- nessun ORM: non è essenziale avere un ORM e personalmente ritengo la conoscenza dell'SQL molto importante, cosa che purtroppo si sta riducendo presso i programmatori più giovani. I vantaggi di un ORM sono comunque molteplici pur avendo, come ogni cosa di ogni disciplina, degli effetti ai quali si deve porre attenzione.
Conclusioni
Photo by Ashley Batz / Unsplash
In un campo tumultuoso come questo, nessuno dotato di onestà intellettuale può ritenere la propria competenza indefinitamente al riparo da marchiani errori architetturali in termini di scalabilità, manutenibilità, sicurezza e molto altro ancora. La ricerca del continuo miglioramento è essenziale per restare anche soltanto al livello minimo di sopravvivenza lavorativa nel settore, perché lo sviluppo software è molto più simile a un processo (spesso di ricerca) che a un prodotto, nonostante quel che i mercanti cerchino di far credere al prossimo.
--