Siamo arrivati alla seconda fase della nostra analisi: dobbiamo stabilire che cosa serve per ogni Goal dal punto di vista “informatico”: Librerie, linguaggi, demoni vari etc. 

Il primo lavoro è quello di ricerca: qual è l’ambiente migliore che vuoi creare per il progetto software? Rischierai l’innovazione, usando il linguaggio e le librerie dell’ultimo grido o opterai per un sistema stabile e ultra-utilizzato? 

La risposta è sempre la solita: dipende.

La prima regola è non seguire a tutti i costi le proprie affinità elettive: anche se adorate il Python non potete far usare solo quello a tutti i vostri clienti. Spesso la vostra mente vi illuderà che il linguaggio o l’ambiente che preferite sia il migliore per il cliente: non sempre è così, cercate di ragionare con obiettività. Restate umili.

Torniamo ora al nostro esempio pratico della scorsa puntata

Cerchiamo di analizzare obiettivamente le reali necessità informatiche dei vari punti che abbiamo enumerato precedentemente:

Una delle prime necessità del passaggio del sito di Wardrome alla nuova versione è la svolta tecnologica: passare da un vecchio sito in PHP5 ad uno moderno, veloce, facile da migrare in più piattaforme se servirà in futuro.

Per un progetto così piccolo non ci sono motivazioni per scegliere un linguaggio o un altro, quindi propendete soprattutto alla facilità di sviluppo e mantenimento: deve bastare una persona a mantenere il software e avere frontend e backend nello stesso linguaggio può facilitare le cose. Un punto a favore di NodeJS.

D’altro canto il software deve avere a che fare con un database mysql del gioco per integrare i pagamenti e i role-blogs. Punto a favore di PHP.

Entrambi i linguaggi attualmente presi in considerazione sono pieni di moduli pronti: il sistema di pagamento è di implementazione equivalente.

Il sito esterno dovrà dialogare con un database mysql organizzato in modo abbastanza caotico e frutto di spaghetti coding. In PHP sarebbe scomodo creare il prodotto con framework dotati di ORM e che si aspettano una congrua organizzazione dei dati.

Questo ultimo punto mi ha fatto decidere per nodeJS, in quanto riorganizzare il dataset sarebbe una operazione molto costosa e lunga; programmare oggi in PHP privi di un framework non è ipotizzabile.

Deciso l’ambiente generale (nodeJS, express, nginx come proxi) si isoleranno le dipendenze NPM minime consigliate per ogni goal e si scriveranno sotto ad ogni punto.

Per quanto riguarda il frontend si tratta di una applicazione web davvero minimale e credo che, nonostante il mio amore per Vue,  un semplice Bootstrap sia più che indicato. In questa analisi sommaria non sono indicati i temi scelti o da realizzare per questioni di rapidità e concisione dell’esempio.

Allego il documento word di questa nuova piccola parte dell’analisi: un documento ancora molto esile come vedrete.

L’uso complessivo delle librerie che risulterà da questa parte di analisi sarà invece trattato nel prossimo articolo, insieme alle parti non-funzionali.

Definire le architetture che formeranno il software