Proseguono le riflessioni sulle competenze ed il ruolo dello sviluppatore Frontend

Design System

Tra le soluzioni progettuali nello sviluppo Frontend quella dei Design System è tra le più recenti ed anche tra le più discusse nell’ambiente. Fino a qualche anno fa il sito internet veniva periodicamente rifatto con una nuova grafica, una nuova struttura delle informazioni e/o con nuove funzionalità; le dimensioni e la complessità dei siti (o applicazioni web) moderni rendono impossibile questa pratica, per cui si preferisce farli evolvere gradualmente nelle loro componenti, rifacendo solo parte di essi o integrando nuove funzionalità in un sistema già rodato.
Questa nuova metodologia comporta però delle problematiche di coerenza sia nell’aspetto grafico che nella usabilità delle interfaccie.
Capita spesso di vedere discrepanze tra le diverse sezioni di un sito: campi di input, pulsanti, spaziature, dimensione dei caratteri differenti creano una sensazione di incoerenza all’interno della navigazione che si rapporta facilmente ad una sensazione di incuria nel branding.
Alla problematica di coerenza di immagine vanno inoltre aggiunti i costi di manutenzione che questa difformità porta con se. Nel momento che l’azienda decide di apportare una modifica, anche minima, all’aspetto grafico del sito il costo va moltiplicato per ogni sezione, dato che l’approcio all’intervento è sempre diverso e dalla complessità variabile. Ogni sezione, poi, rimane strettamente legata allo sviluppatore che l’ha fatta, il quale, in mancanza di una linea guida predefinita, ha fatto una implementazione in base alle sue esperienze e preferenze; un eventuale passaggio di consegne diventa quindi un costo aggiuntivo.
Il design system serve proprio ai risolvere questi problemi di incoerenze e di gestione dei costi, ma quali sono le competenze richieste?
Tanto per iniziare voglio specificare che il design system può essere puramente grafico, quindi composto da immagini statiche e da una descrizione del loro uso, ma anche vivente quindi implementato direttamente in HTML/CSS/JS. Nel secondo caso abbiamo un sistema che richiede competenze di sviluppo più avanzate, ma che è più facile da mantenere nel tempo e che detta non solo le regole estetiche ma anche quelle implementative. In ogni caso la figura destinata ad implementare il design system deve essere in grado di comprendere l’architettura di base a cui deve essere applicato il sistema, ed ha la responsabilità di prendere diverse scelte progettuali sulla strutturazione dei componenti dell’interfaccia, scelte che avranno un effetto a cascata su tutte le sezione del sito o dell’applicazione.
Gli strumenti a disposizione sono tantissimi e la loro scelta dipende principalmente dalla tecnologia di base e dalle competenze di chi si occupa dello sviluppo: al developer conviene studiare quello che si adatta meglio al suo background ed alle sue conoscenze.
Software di design come Sketch, Figma, Adobe XD o Zeplin sono in grado di esportare design system in maniera automatica, anche se in alcuni casi solo a livello visivo; chi sviluppa già in componenti React/Vue/Angular potrebbe preferire Storybook o Fractal, oppure ci sono strumenti nati appositamente come Pattern Lab o Docsify.

Skin/Theme Development

Questo incarico è quello che si identificava maggiormente con la figura del Frontend Developer, in quanto prevede lo sviluppo massimo delle 3 competenze di base (HTML/CSS/JS), ed è quello che ha il compito di convertire il wireframe in un sito/applicazione funzionante usando come riferimento il design system.
Pur trattandosi di una fase del progetto puramente esecutiva ci sono ancora importanti scelte strategiche da fare che hanno un impatto fondamentale soprattutto sulla stabilità del frontend stesso e sulla sua mantenibilità.
La prima competenza specifica riguarda sicuramente la piattaforma sui cui si sta lavorando; a parte rarissimi mini-siti promozionali, la maggior parte dei frontend consiste nell’implementazione di un tema per un software di data management.
Il modo in cui si sviluppa il frontend per un sito in Wordpress o in TYPO3, per un e-commerce in Magento o su Salesforce cambia radicalmente (per non parlare delle piattaforme headless) e ad un livello professionale non è possibile improvvisare; lo studio e la specializzazione su questi software è pertanto una competenza basilare: forzare oggi un sistema ad adattarsi al nostro modo di lavorare può comportare solo imprevisti e problemi in un prossimo futuro, spetta allo sviluppatore conoscere ad adattarsi alla piattaforma per esaltarne le funzionalità.
Il linguaggio CSS appartiene alla categorie dei “easy to learn, hard to master”, basti solo pensare alla miriade di configurazioni possibili all’interno delle specifiche di Grid per lo sviluppo di layout complessi, che però possono tranquillamente essere ignorate usando specifiche meno efficienti ma più immediate da imparare.
Una delle competenze relative ai CSS non è pero collegata al linguaggio stesso, ma a come viene utilizzato in progetti di grandi dimensioni. Un progetto corporate può avere migliaia di righe di codice CSS, per poter essere mantenibile deve basarsi su una architettura solida e coerente altrimenti i costi nel tempo cresceranno esponenzialmente, con la stabilità a fare il percorso opposto calando drasticamente con una profusione di bug.
Per avere un codice CSS strutturato al giorno d’oggi si fa affidamento soprattutto sui pre-processori (Sass, Less, Stylus) o sui post-processori (PostCss), che consentono di usare paradigmi tipici della programmazione (variabili, funzioni, modularità…), a cui va aggiunta una conoscenza anche di base degli strumenti di building automation o di bundling (Grunt, Gulp, Webpack …). Relativamente alle scelte progettuali ci sono diverse architetture esistenti e documentate (OOCSS, SMACSS, ITCSS, Atomic CSS ...) che una volta imparate possono portare allo sviluppo di nuove soluzione più specifiche al progetto sui cui si sta lavorando. Nell’utilizzo di una architettura CSS molta importanza ha la naming convention che ne deriva, in questo caso ci sono due linee di pensiero principali che sono: l’utilizzo di classi generiche che definiscono unicamente lo stile (es. Tachyons, ma è una caratteristica di tutti i framework css generalisti) oppure l’uso di nomi che rappresentano il componente, con BEM a farne l’esempio più seguito.
Siccome CSS non è un linguaggio strutturato con regole rigide è importante darsi e seguire delle corrette coding guidelines, in modo da avere un codice condiviso e leggibile: a supporto esistono diversi strumenti, come css-lint o eslint, che possono essere integrati direttamente negli editor in modo da avere segnalazioni in tempo reale sulla qualità del codice prodotto.

Altre risorse

https://github.com/stubbornella/oocss/wiki
http://smacss.com/
https://www.xfive.co/blog/itcss-scalable-maintainable-css-architecture/
https://acss.io/thinking-in-atomic.html
https://cssguidelin.es/
https://css-tricks.com/

La parte 1 la trovi qui
La parte 3 la trovi qui
La parte 4 la trovi qui