Git Me Baby One More Time
Il version control ha reso il mio processo produttivo più efficace, più reiterabile e aperto alla condivisone anche con chi non è un designer, ma per i file binari c’è ancora molta strada da fare.
Il 2018 è stato per me l’anno che mi ha introdotto definitivamente al mondo del version control e alle enormi potenzialità che esso ha per il design, il workflow e la produttività in generale.
Prima, nella mia beata ignoranza, «version» e «control» erano una coppia di parole che si scambiavano i dev nel loro linguaggio misterioso.
Poi, lavorando con quelli che poi sono diventati il mio team e i miei soci nella start-up che abbiamo fondato, abbiamo impostato le metodologie di lavoro per tutti e quattro e guarda caso che parola salta fuori?
Version control.
Seguita da qualcosa come Git.
E poi GitHub.
Cose che nel mio archivio e background design-only non trovavano riferimenti e connessioni.
Ma facendo prove, lavorandoci e seguendo quello che faceva il resto del team, il version control mi ha davvero aperto un mondo.
E diciamo che questa non è una storia che racconta come funziona il version control: non ha senso stare a inventare l’acqua calda e ripetere quello che praticamente compone il 79% delle storie su Medium.
In questa storia ci sono tutte le riflessioni legate al mondo del design e al suo avvicinarsi al mondo del version control.
I concetti chiave
Il meccanismo base del version control ruota attorno a otto concetti fondamentali:
- master file, il file principale, con la versione del codice più aggiornata;
- repository, ovvero il «deposito» dove sono contenuti dei files;
- cloning, il processo di copiare i file da un repository centrale e distribuito a un altro repository
- push, ovvero «spingere» le modifiche locali al repository online
- pull, ovvero «tirare giù» la versione più aggiornata del repository di riferimento;
- commit, è l’insieme delle modifiche effettuate sul e al file — sono composte da una serie di diff, le modifiche specifiche;
- merging, avviene quando il commit viene accettato ed è la fusione dei commit nel master file.
A tutto ciò possono essere aggiunti:
- issue tracking, individuazione di ogni genere di entità su cui voler intervenire (che sia un bug, un aggiunta o un miglioramento);
- pull request, fase dove viene sottoposto a revisione tutto il set di modifiche attuate prima del merging.
I vantaggi
Grazie a tale meccanismo, un team anche corposo può lavorare sullo stesso file contemporaneamente, senza andare a intaccare il file principale e riempire di copie e alternative il repository finale a cui tutti fanno riferimento.
A livello di produttività, è oro puro.
Ogni membro del team può lavorare su una task personale o assieme a un altro collega e reiterare di continuo, lavorando su feedback anche in tempo reale.
Basta fare un branching dal repository principale e poi sottoporre il proprio commit al team e aspettare l’eventuale merging.
E un team che comunica è come un meccanismo ben oliato e produce bene.
Adottare la mentalità del versioning è un boost potente per un team, specie se di dimensioni ridotte, perchè permette di lavorare in asincrono senza avere costanti sessioni di sync.
Diciamo che, a livello pratico, la necessità di fare riunioni di sincronizzazione del team si riducono drasticamente, perchè permettono di spostarle in real time online, aiutate soprattutto dall’issue tracking e dal meccanismo di commit e pull request.
Il guadagno per il team, inoltre, non è solo a livello di produttività e di reattività, ma anche di integrità dei dati.
Il master file non viene attaccato anche con centinaia di modifiche proprio perchè, prima di essere accettate, si revisionano e controllano le modifiche avvenute a livello intermedio nelle varie branch — le modifiche effettuate sono quelle desiderate e volute.
E grazie al push-and-pull, fatta ogni modifica l’intero master file rimane aggiornato in tutte le versioni clonate in altri repository.
E i designer?
Non è da molto che questo vocabolario e questa metodologia hanno a iniziato a essere sempre più diffuse anche nel mondo del designer medio.
Più che semplice desiderio di innovazione, era una risposta alla necessità di non morire sepolto da un sacco di final.sketch, final_final.sketch, final-version-for-real2-final-version-complete.sketch e altre copie.
Senza version control, una libreria o und design system sono improponibili opere titaniche di mantenimento.
In questi casi, infatti, il merging viene affidato a una persona singola che riceve tutti i file e controlla che tutti abbiano quello aggiornato con le modifiche accettate nei meeting.
Anacronistico, soprattutto se si vuole lavorare agile, reiterando e testando e cercando di rimanere sempre sul pezzo nella gestione del prodotto.
Il version control ha gli stessi benefici a livello di produttività che adesso si possono riscontrare nel mondo del coding:
- collaborazione asincrona, che permette di occuparsi di più task diverse in contemporanea, senza lavorare con un processo sincrono e lineare di successione cronologica temporale delle task;
- testing, perchè nuove funzionalità possono essere testate o sperimentate senza andare a intaccare la master;
- accessibilità, perchè chiunque può mettere mano al main repository;
E tutto ciò si traduce in:
- efficienza, dove i tempi morti, le ripetizioni o il mancato aggiornamento sullo stato dell’arte vengono ridotti al minimo;
- produttività, direttamente connessa all’efficienza, perchè un team efficiente è produttivo;
- soddisfazione del cliente, dal momento che il prodotto può essere progettato, implementato, testato e reiterato per venire al meglio incontro ai bisogni del cliente;
- soddisfazione del team che può lavorare senza troppe interruzioni, può rimanere in sync e proporre modifiche personalizzate e arbitrarie da sottoporre a revisione.
Ma non è tutto oro quel che luccica.
Il version control è nato principalmente per il codice — è basato su file di tipo non binario (ovvero testo), quindi i moderni client che permettono l’hosting di servizi di version control distribuiti (come lo è GitHub per Git) sono ottimizzati per visualizzare quel testo e individuarne le diff.
I software usati dai designer, invece, producono file di tipo binario proprietario.
Di nuovo, il mondo del design si trova in asincronia con il mondo del dev.
È una differenza culturale che continua a mettersi in mezzo alla pacifica iterazione tra dev e designers e spesso spinge i due mondi a settorializzarsi in comparti stagni.
Per ora, i client usati per il coding non vanno bene per i file binari — sono nate però delle soluzioni:
- design only, dove è possibile fare versioning di file binari (per ora solo proprietari SKETCH), quali Abstract, il più completo, e Plant, a esempio;
- integrazione design e coding, come Kactus, dove è possibile visualizzare tutto il repository, sia che ci siano file binary di SKETCH che file di testo.
Non proprio, perchè la nascita di questi tool non va a risolvere l’effettivo problema che il mondo del designer non riesce a produrre file standard visualizzabili indipendentemente dai tool — se vuoi legegrne di più, ci ho scritto un articolo👇🏻
E dunque?
Allo stato delle cose, soluzioni come quelle offerte da Kactus e Abstract rappresentano davvero delle innovazioni produttive, ma il futuro del design davvero open e compatibile, a mio parere, risiede altrove.
Potrebbe risiedere in una mescolanza delle due realtà anche a ruolo professionale — designer che sappiano implementare gli elementi che producono, creando librerie e interfacce direttamente col codice per le revisioni future e usare software che producono file binari solo per prototipazioni, modelli o brain-storming e showcasing.
I due mondi, design e development, sono così legati che non ha senso che siano stagni uno all’altro e che i professionisti dell’uno siano completamente a digiuno dei meccanismi dell’altro.
A esempio, un designer che sappia implementare in front-end i componenti della libreria che ha progettato potrebbe essere il futuro, ma anche sviluppatori che partecipano al progetto di prototipazione e progettazione e implementano quanto progettato.
Un’altra soluzione potrebbe venire dai software stessi, che potrebbero produrre file standard (come gli SVG) e non file binari, anche perchè client come GitHub permettono di visualizzare le diff degli SVG e le loro anteprime in maniera visiva senza aprire nessun software di terze parti — rispetto alle PNG, inoltre, gli SVG sono manipolabili da qualunque software vettoriale (come Illustrator, Adobe XD, Framer o Sketch App).
