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.
