Il consiglio di un mio amico, trent’anni fa, mentre ci accingevamo a fare una passeggiata in Barbagia, era sensato: porta con te qualcosa che ti possa essere utile per ogni evenienza, metti che ti va un fico d’india o vuoi raccogliere asparagi.

In ogni mestiere ci sono dei “tool” che ci accompagnano, ci servono a migliorare il nostro lavoro, a farci sentire più sicuri.

Personalmente ho attraversato talmente tanti anni nel mio percorso da developer: non provo particolare affezione per un IDE.

Uso attualmente soprattutto VSCode e VIM (quando sono davanti ad una cli: non fate finta di niente, lo so che non sapete uscire da VIM e usate NANO) ma cambierei IDE senza nessun problema a seconda di come tira il vento, le comodità a cui ci si abitua in fretta su VSCode e simili, non ci sono sempre state, e per uno della mia esperienza non sembrano sempre necessarie.

Alcuni tool invece risultano estremamente necessari e totalmente irrinunciabili.

Inutile dire che un mondo senza GIT sarebbe un mondo molto triste, in cui i developer salverebbero i file in cartelle con nomi tipo “ultimo-ultimo prometto ultimo”.

GIT oltre che un tool è un processo di sviluppo, che deve essere chiaro a tutti nelle sue meccaniche, che vanno dall’apertura delle issues, dai commit ai rebase, alle PR e CR risultanti: in azienda occorre un manuale operativo scritto che spieghi a tutti quali sono i processi e come li gestiamo, non tutti i team sono uguali, c’è chi preferisce GitHUB, chi GitLAB, c’è chi preferisce usare i tag per le versioni, chi ha una pipeline di CI/CD scritta in un modo, chi in un altro.

L’importante del processo GIT è che esista, che abbia senso compiuto, che sia stato discusso nel team, che si tenda a migliorarlo, che sia comprensibile ed accettato da tutti.

Metterei tra i tool obbligatori anche un linter, non è accettabile che un developer usi il camel case, un altro lo snake case, che le parentesi siano formattate diversamente: avere un linter configurato nello stesso modo per tutto il team evita questo disordine.

Anche qui si tratta di un processo oltre che un tool: va decisa la convenzione di scrittura collegialmente e poi va rispettata da tutti.

Serve un tool che generi la documentazione (sì, il codice dovete commentarlo) automaticamente e magari la pubblichi subito con una github action o similari.

Idealmente nell’ottica di avere una documentazione completa e aggiornata consiglio anche di approcciarsi alle api con una modalità contract first e usare gli appositi tool per generare la documentazione dai contratti.

Qualsiasi sia il linguaggio, per evitare più guai possibili, tipizzate se il linguaggio lo permette, e scrivete sempre i test.

Oggi inoltre rientra nei requisiti di sicurezza e di logica depositare le proprie librerie comuni e quelle usate in una repository privata, stile npm e similari.

Questo processo è un po’ legnoso inizialmente ma vi darà maggior controllo su tutto quello di cui il vostro software abbisogna.

Credo di aver nominato i tool irrinunciabili ad un developer che lavora in team: segnalatemi pure cosa aggiungereste a questa lista.

Ho volutamente tralasciato i software di comunicazione, di product design e di planning.