Esistono molti modi di organizzare un ambiente di sviluppo orientato al web. L'approccio professionale più diffuso è ricorrere ad un IDE, come ad esempio Eclipse o NetBeans. Questa è una scelta praticamente obbligata quando si lavora in team, allo scopo di condividere metodologia di sviluppo e strumenti di lavoro. Di contro, quando lavoriamo da soli su un progetto di modeste dimensioni, ad esempio un sito personale o un blog, la scelta dell'IDE potrebbe risultare sovradimensionata o scomoda.
Abbiamo già visto le potenzialità di alcuni editor, tra cui ad esempio l'editing in colonna offerto da Notepad++. Queste funzionalità, unite alla leggerezza dello strumento, sono un punto a vantaggio degli editor light nei confronti degli IDE, specialmente per progetti di ridotte dimensioni.
Un altro aspetto da prendere in considerazione quando scegliamo gli strumenti di lavoro è la configurazione dell'ambiente di sviluppo. Gli IDE tendono ad organizzare l'ambiente di sviluppo “al loro interno”, creando configurazioni virtuali degli elementi necessari. Un'alternativa è quella di creare un ambiente di sviluppo web che potremmo definire “agile”, che può risultare più efficiente se il progetto è di modeste dimensioni, eventualmente sfruttando qualche CMS (come ad esempio WordPress). Un esempio di questo tipo è illustrato in questo articolo.
Ma l'aspetto forse più importante è l'approccio al debug del software. Chi da per scontato la scelta dell'IDE spesso ignora che nella comunità degli sviluppatori esiste una sorta di scisma fra due scuole di pensiero, che potremmo riassumere nel motto IDE versus Logging.
Da una parte abbiamo il debug tradizionale degli IDE, che si basa sull'introduzione di opportuni breakpoint nei sorgenti, allo scopo di steppare nel codice facendo girare il nostro programma in modalità debug. Questo è l'approccio più usato in caso di produzione di software su scala industriale (ma non sempre). L'altra scuola di pensiero rinuncia al debug dell'IDE, o lo limita al minimo necessario, concentrandosi sull'inserimento opportunamente calibrato di un sistema di logging granulare e configurabile. Spieghiamo l'importanza dei termini appena usati.
- Opportunamente calibrato: il sistema di logging deve essere tarato con un occhio di riguardo alle performance, e deve essere attivabile e disattivabile senza dover ricompilare il codice
- granulare: i messaggi di logging devono essere puntuali e precisi, tracciando con una precisione di circa 10 righe di codice qualsiasi funzione del software
- configurabile: deve essere possibile impostare la soglia del logging, scegliendo ad esempio tra i livelli debug ,info, warning e fatal senza dover ricompilare il codice
Proviamo quindi a riassumere i vantaggi e gli svantaggi delle diverse opzioni considerate, che sono:
- IDE con integrato un ambiente di debug
- Editor light con codice orientato al logging
Una tabella comparativa dei vari aspetti potrebbe essere
| Aspetto | IDE | Light |
|---|---|---|
| Lavorare in Team | SI | NO |
| Controllo di configurazione | SI | SI |
| Semplicità | NO | SI |
| Velocità | SI | NO |
| Debug in sviluppo | SI | SI |
| Debug in test o produzione | NO | SI |
Spieghiamo il significato della tabella. Per semplicità consideriamo i tempi di configurazione, aggiornamento, integrazione e la learning curve dell'utilizzatore. Un IDE è certamente uno strumento di classe superiore, ma per piccoli progetti i costi iniziali necessari ad avviare gli sviluppi sono sovradimensionati: il gioco potrebbe non valere la candela.
Con Velocità intendiamo l'insieme delle funzioni che rendono più veloce lo sviluppo del codice, come ad esempio l'autocompletamento e la possibilità di inserire automaticamente pezzi di codice (un esempio classico è l'aggiunta di metodi setter/getter).
Il debug in sviluppo è il normale debug che svolgiamo in locale, sulla nostra macchina. Sotto questo aspetto i due approcci sono equivalenti: spesso un buon debugger risulta più efficace dell'analisi del log, ma a volte il debugger non riesce a trovare i sorgenti colpevoli del problema, e in quel caso il log può risultare più efficiente.
La situazione cambia nel debug in produzione, dove spesso il nostro software gira senza essere (facilmente) collegabile ad una qualche IDE. In questo caso un buon sistema di logging può farci risparmiare ore di lavoro, perché nessun ambiente di sviluppo è identico a quello di produzione, per cui il modo più sicuro di scovare i bug della produzione è quello di analizzare il software live, anziché quello (solo teoricamente uguale) che gira sulla nostra macchina.
Precisiamo un aspetto importante di questa analisi. Nulla vieta di inserire un buon sistema di logging anche quando utilizziamo un IDE, ma è un dato di fatto che la scelta dell'IDE spesso limita la granularità del logging. Il motivo è che lavorando con un IDE mettiamo già in conto, nella gestione del progetto, i tempi (e i costi) necessari a familiarizzarci con lo strumento, configurarlo, installare i framework necessari, ecc. Alla fine è inevitabile che quando si arriva allo sviluppo del codice si vuole recuperare l'investimento fatto, per cui si spinge tutto sul codice autogenerato dal framework e dell'IDE, e non si trova il tempo di inserire un sistema di logging con un'elevata valenza semantica. In altre parole: rischiamo di non sapere cosa fa esattamente il "nostro" codice ma, sopratutto, rischiamo di non sapere perché fa quello che fa.
In conclusione non esiste uno strumento migliore dell'altro, vantaggi e svantaggi di ciascuna scelta diventano cruciali (o trascurabili) a seconda del contesto preciso di un progetto. Spetta a noi capire cosa dobbiamo fare, valutare costi ed obbiettivi e poi scegliere lo strumento più adatto all'esigenza. A ciascuno il suo!
