Qualcuno ha riconosciuto la citazione? Siamo in Iron Man, il film del 2008 con Robert Downey Jr. Una di quelle citazioni che per qualche motivo ti rimane impressa e, un bel giorno, ti torna utile.
La frase infatti viene usata quando, per scappare dai terroristi che lo tengono prigioniero, Tony Stark sta finendo di preparare la prima versione dell’armatura che lo renderà un eroe.
Non deve essere bello, deve funzionare!
La prima versione del vostro prossimo progetto non deve essere la versione ideale. Questo vale SOPRATTUTTO se siete sviluppatori.
Molti degli sviluppatori che conosco sono dei perfezionisti nel senso negativo del termine: si concentrano talmente tanto sui dettagli che perdono di vista la big picture. Il risultato? Il progetto non finisce mai in produzione.
Tanto, parliamoci chiaro: al 100% degli utenti fregherà zero del fantastico design pattern che avete applicato. Agli utenti frega che l’app FUNZIONI. Sticazzi se la prima versione la fate con jQuery nel 2021. jQuery è bellissimo.
Non ci marciate troppo però, e ricordate:
- GLI MVP VANNO RISCRITTI SEMPRE;
- SCRIVETE I FOTTUTI TEST;
A proposito dei test, voglio darvi un consiglio che mi ha salvato la vita tante volte. Una delle obiezioni che facciamo più spesso alla scrittura dei test è che non abbiamo tempo. Vero, a volte il tempo non c’è… ma non può essere una scusa! Sicuramente, quando buttiamo giù una prima iterazione di un nuovo software è difficile avere una coverage al 100%.
Nel mio caso, adotto queste quattro semplici regole:
- mi assicuro che vengano testati i componenti più critici: nel mio caso, la classe più testata di tutta la codebase è quella che calcola i nuovi prezzi dei prodotti;
- mi assicuro che vengano coperti gli happy path: nel mio caso, mi sono assicurato che a partire da una richiesta di cambio prezzi quella richiesta venga rispettata;
- se non ho tempo di testare tutti i dettagli, testo almeno la big picture: nel mio caso, ho creato un development store su Shopify appositamente per i miei test, su cui li faccio girare. Questo approccio ha i suoi limiti, ovvio, ma mi ha salvato le chiappe più di una volta;
- ho risolto un bug? Bene, ci scrivo un test: mi costa poco ed aggiunge un pezzetto di stabilità in più alla codebase;
Usa una tecnologia che già conosci!
Per la prima versione dell’armatura, Tony Stark parte da qualcosa che già conosce: il reattore Arc.
Allo stesso modo, partite sempre da una tecnologia che conoscete bene, perché sarà su quella che dovrete lavorare quando la nuova feature che avete rilasciato da poco farà saltare in aria tutto.
A mezzanotte. Il giorno del black friday.
Per Ahia, ad esempio, sono partito usando solo ed esclusivamente Laravel e React, su cui ho un’esperienza sufficiente a stare sereno. E sapete cosa? Continuano a funzionare alla grandissima anche oggi. Ah, altra nota: partire con una droplet da 10 dollari su DigitalOcean, fidatevi, va più che bene. Nel mio caso specifico, se l’è cavata alla grande fino a 1000 installazioni.
Non temporeggiare!
Un’altra delle cose in cui molti sviluppatori non sono buoni per niente è andare in produzione. Magari si mettono d’impegno, fanno tutto quello che devono e poi puff, si perdono durante l’ultimo miglio. Il copy delle pagine, la mail da mandare, gli ultimi ritocchi.
- Cercate di pensare a step. Fatevi una lista, se necessario (prima di ogni messa in produzione io una lista la faccio sempre) ed agite!
- Non iniziate altri progetti prima di aver mandato in produzione quello “attuale”. Usatela come regola aurea. Notate bene: ho usato “mandato in produzione” e non “finito“. A finire non finirete mai, mettetevi l’anima in pace;
- Non abbiate paura dei feedback negativi, sono quelli che vi aiutano a crescere (non il “quanto sei bravo” di mammà). Anche dietro quelli più spietati, a volte, c’è un’esigenza di un utente. Potete imparare qualcosa anche da una risposta maleducata, a volte;
Lesson(s) Learned: allenatevi a riconoscere il superfluo ed imparate a lasciarlo andare. Preparate delle liste. Tante liste di step il più possibile concreti. Un esempio? “Informarsi sulla fattibilità della feature X” non è concreto, “chiedere a Z se è possibile implementare la feature X entro Y” invece lo è.
Un side-project alla volta è più che sufficiente, non iniziatene un altro prima di aver mandato in produzione quello “attuale”. Di domini, invece, ne potete comprare quanti ne volete, tanto a chi vogliamo darla a bere? Costano così poco e sono così invitanti…
