Qualche giorno fa ci siamo imbattuti in un elenco trovato in rete, uno dei tanti che si proponeva di elencare i 10 strumenti che qualsiasi programmatore Java utilizza (o dovrebbe utilizzare) nella sua quotidianità.
Al di là delle voci in sé, molte delle quali erano secondo noi discutibili, ci ha dato uno spunto per riflettere sul nostro lavoro.
Facciamo un po’ di ordine. Cosa fa uno sviluppatore durante la sua giornata? Dipende. Però, essenzialmente, scrive codice, lo controlla, lo compila e lo condivide. I veri must have quindi non sono tanto tools e programmi (per i quali esistono sempre delle alternative), ma ottenere codice di qualità, adottare un processo di build semplice e automatizzato, condividere e accedere al materiale condiviso con facilità per lavorare in modo concorrente. Teniamo a mente, perché è essenziale, che sono gli scopi a determinare gli strumenti.
Noi qui per scrivere codice non abbiamo uno strumento unico che tutti usano. C’è chi si trova bene con Eclipse, chi per necessità di sviluppare frontend usa VSCode o Atom. Vuoi usare IntelliJ? Va bene, come desideri. L’importante è che qualsiasi altro collaboratore possa lavorare senza problemi sul codice che tu hai scritto. Quindi, al di là della scelta di uno strumento più o meno potente (o anche più o meno “figo”), è bene controllare che quest’unica caratteristica sia rispettata perché altrimenti non c’è bisogno di spiegarti quanti e quali problemi possano venirne fuori.
Poi c’è Git, uno strumento utilissimo per versionare il codice e abilitare più sviluppatori a lavorare contemporaneamente in modo sicuro. Anche in questo caso esistono diverse alternative, una su tutte SVN che, nonostante si sia fatto soffiare lo scettro da Git negli ultimi anni, è comunque tutt’ora molto utilizzato.
Poi è anche necessario un procedimento di automatizzazione di sviluppo e pacchettizzazione del codice.
Anche qui i tools sono vari: Maven o Gradle sono fondamentali per la gestione delle dipendenze e del processo di build, mentre Jenkins è tra gli strumenti più noti per la parte di Continuous Integration. Questa parte del lavoro è così cruciale che quando valutiamo i curriculum cerchiamo sempre la riga in cui sono specificati gli strumenti usati dal candidato. Anche solo per essere certi che abbia capito l’importanza di questa fase.
Infine, la necessità di avere codice di qualità ci porta all’analisi statica del codice (per cui esistono tanti strumenti, uno su tutti Sonar). Anche qui parliamo di una questione non opzionale e spesso sottovalutata anche dai committenti, soprattutto se sono grandi aziende con molta fretta. Per noi è una questione di metodo con risvolti importanti sia di tempo che economici: meglio è condotta la fase di controllo qualità del codice e di test, più è il tempo che si risparmia, migliore la qualità del prodotto finale, maggiore il guadagno ottenuto. Non è proprio il caso di escludere questi strumenti dalla lista.
Al di là di tutto, però, è bene mettere in chiaro un concetto fondamentale che molte volte sfugge: i tools contano meno delle buone pratiche. E’ a quelle che dobbiamo dare importanza. Versionamento del codice, testing, analisi statica del codice, analisi della qualità interna: sono tutte pratiche che possono essere messe in atto con molteplici strumenti, l’importante è che vengano messe in atto.
Insomma, un buon pittore farà un bel quadro anche con pochi colori e un solo pennello. Un cattivo pittore invece, se anche avesse tutti i migliori strumenti del mestiere, non otterrebbe lo stesso risultato. Tecnica, metodo, buone pratiche.
In ogni caso è vero che certi strumenti si scoprono a volte tardi, spesso solo quando si viene immersi in un vero flusso di lavoro e si deve imparare in fretta per allinearsi al resto della squadra. Un altro progetto che realizzeremo a Jaewa sarà proprio una serie di corsi mirata a colmare queste lacune attraverso una formazione mirata e casi di studio.