Creare un'applicazione, in fin dei conti, è una questione di scelte. Ci sono sempre svariati modi di fare le cose, diversi approcci, molte tecnologie. Scegliere le migliori componenti e far sì che funzionino insieme è uno dei compiti primari del nostro lavoro, soprattutto in realtà dove i ruoli di analista, progettista e sviluppatore coincidono o si sovrappongono almeno in parte.
Puà sembrare un discorso astratto o tautologico se si pensa alle componenti fondamentali di un sistema LAMP (Linux, Apache, MySQL, PHP), ma assume concretezza quando ci riferiamo ad elementi meno scontati, come il framework di sviluppo, le librerie Javascript, il sistema di caching o di templating, l'ambiente IDE, il sistema di deploy, ecc.
Sbagliare la scelta di una di queste componenti può essere disastroso per la riuscita dell'applicazione e per la sua sopravvivenza sul lungo periodo. Mi sono chiesto dunque quali possano essere i criteri per fare delle buone scelte in questa materia e ne ho individuati sei.
0. Mi serve? ovvero ne posso fare a meno?
Prima di tutto è indispensabile rendersi conto se quello che stiamo scegliendo è necessario al progetto: non c'è scelta peggiore che infarcire l'applicazione di elementi sottoutilizzati o del tutto inutili o che possono essere sostituiti con poche righe di codice scritto ad hoc.
1. È buono? Stabilità , performance, sicurezza
La bontà del componente è centrale. Un elemento instabile, con performance incerte o problemi di sicurezza noti non è un buon compagno di viaggio e dovrebbe essere scartato. Tuttavia la valutazione dovrebbe essere unitaria e non limitarsi a valutare singolarmente i tre principi.
2. Lo so usare? Familiarità , documentazione, test
Cercare di risolvere un problema e avere come unico supporto il codice scritto altri, senza poter contare su documentazione di alcun tipo, non è una buona sensazione. Per questo credo sia essenziale che le componenti scelte ci siano familiari, almeno nei concetti fondamentali e nella struttura, che siano accompagnate da una esausitiva documentazione tecnica e che sia necessario testarle al di là dell'uso che se ne intende fare.
3. Durerà ? Longevità , roadmap, supporto
Chi intende produrre applicazioni capaci di durare anni e non vuole riscrive da capo il codice ad ogni nuova release deve, inevitabilmente, fare i conti con il concetto di longevità . Prima di scegliere un componente mi chiedo sempre chi lo produce e verifico il lavoro che è stato fatto in passato, come il numero di bug segnalati e il tempo di risoluzione, la regolarità nel rilascio delle versioni, ma soprattutto verifico la roadmap di sviluppo, dato essenziale per capire se quella specifica componente crescerà di pari passo alla mia applicazione e nella direzione a me più congeniale.
4. È conosciuto? Community, diffusione, codice sorgente
Non sempre i prodotti più diffusi sono i più buoni. Diciamo però che più un prodotto è conosciuto, sia nel senso di notorietà che di consapevolezza, più è probabile che siano disponibili le informazioni utili al raggiungimento del miglior risultato. La conoscenza profonda, poi, quella derivata dalla disponibilità del codice sorgente, è certamente da preferire, perché, tra le altre cose, ci protegge in qualche misura dagli scenari catastrofici del punto 5.
5. Lo posso sostituire? Sostituibilità , refactoring
La possibilità di dover sostituire una componente è una possibiltà concreta, spesso traumatica, ma giocoforza inevitabile. Uno sviluppatore che abbondona un progetto, un plug-in che non segue i tempi di sviluppo del core, un'azienda che cambia gestione, ecc. sono tutti eventi che possono, anche nel breve periodo, influenzare la "tenuta" delle nostre scelte. Per questo è necessario capire (almeno in linea teorica) se è possibile sostituire la componente scelta e quali saranno le ripercussioni sulla nostra applicazione.
Queste sono le sei domande che mi pongo per una valutazione tecnica delle componenti software che integro nelle mie applicazioni. Non è certo un compendio esaustivo, ma può essere un buon punto di partenza che spero vi sia utile!
