Luca Colonnello
Principal Engineer, Trainline
How to deal with Front-End
at scale
luca colonnello
Principal Software engineer
@LucaColonnello
Perchè parlare di scalabilità?
⏳ Condividere esperienza
📣 Avviare una conversazione e imparare
👩💻 🧑💻 Parlare delle opportunità di crescita
nel mondo Front-End
Cosa vorrei portaste a casa
Sfide e problematiche
Conway's law
Pattern / Architetture
Strutture organizzative
Carriera e ruoli
Concetto di ownership
DI CHE
DIMENSIONI PARLIAMO
<10
Più facile da gestire
Meno persone, meno spese
Più veloce in comunicazione ed esecuzione
Più veloce nel prendere decisioni
VANTAGGI DI UN Azienda PICCOLA
Perché le aziende hanno bisogno di far crescere il proprio team?
Più work stream in parallelo
Meno context switching
Diversificazione del business e ROI
🧑💻 👩💻 Più persone
🤝 Più team
📑 Più progetti
👩💼 🧑💼 Più management
quali SFIDE
DOVREMO
AFFRONTARE
architettura SOFTWARE tipica
Solitamente monolita
1. Lavorare in 600 allo stesso codice
<10
>100
=>
😞 Facile avere conflitti
😞 Richiede coordinazione delle modifiche sulle stesse parti di codice
😞 Non si sa chi sa cosa e chi è responsabile per cosa
La chiave è un architettura modulare, accompagnata da una chiara ownership
La struttura organizzativa è direttamente correlata all'architettura che scegliamo
e influenza i layer di management e i processi
adattiamo la nostra architettura
open / close principle
ownership dei domini
più isolato, meno conflitti
costo condivisione basso
costo manutenzione tooling basso
coordinazione per release
scala in modo totalitario
app indipendenti
ownership dei domini
codice completamente isolato
release indipendenti
scala in modo indipendente
costo condivisione elevato
costo manutenzione tooling elevato
La domanda a cui rispondere deve essere
Qual è il costo di un cambiamento, e quale tipo di cambiamento avviene più spesso?
2. impatto sulla user E DEV experience
Le scelte di architettura nel front-end hanno diretto impatto sull'esperienza utente
Team isolati possono fare scelte diverse,
e questo ha vantaggi e svantaggi
performance
possibile ottimizzare app in modo indipendente
costo di ottimizzazione basso
(0 tech stack coupling)
duplicazione runtime e librerie di utility nel layer condiviso
Definendo constraints chiari per il tech stack del layer condiviso, possiamo mantenere questo layer il più snello possibile, evitando duplicazione a runtime e quindi impatto alle performance
CUSTOMER LEARNING CURVE
troppo isolamento può portare alla mancanza di allineamento nel processo di design, peggiorando la user experience
Implementando e adottando un design system, possiamo unificare il linguaggio, i pattern e l'esperienza utente (e molto altro)
DEVELOPER EXPERIENCE
autonomia di team e ownership delle scelte
possibilità di esplorare nuove tecnologie e portare innovazione
on boarding necessario per muoversi di team o creare feature cross domain
Allineando il tech stack, pur mantenendo la modularità e indipendenza dei team, riusciamo a garantire agilità la capacità di spostare persone senza incorrere in costi eccessivi di on boarding
3. Manutenzione / evoluzione / ownership
Più feature e tooling condividiamo, più aumenta il coupling tra le applicazioni
Chi è l'owner di queste feature e tooling, e chi si preoccupa dell'evoluzione e manutenzione?
Come manteniamo tali feature e tooling condiviso aggiornate in tutte le applicazioni?
SHARED OWNERSHIP = NO OWNERSHIP
La manutenzione e l'evoluzione spesso e volentieri passa in secondo piano
Le persone che hanno più conoscenza / esperienza, diventano punti di riferimento, ma non vengono rimpiazzate se lasciano la compagnia
Per evitare questi problemi, se vogliamo avere librerie condivise, dobbiamo accettare il costo di manutenzione e ownership
È preferibile assegnare tali librerie ad uno o più core team, accettando contributions esterne (ispirandosi all'open source)
tenere tutto aggiornato
Questo crea app di prima e seconda classe, con un impatto notevole sulla customer experience nel lungo termine
Possiamo risolvere il problema in diversi modi
Mantenendo l'albero delle dipendenze il più piatto possibile
Semplificando
(sopratutto il tooling)
esbuild
Rome
Installando dipendenze
a runtime
module federations
o semplice HTML SSR
monorepo
opportunità
di crescita
e avanzamento
I problemi di cui abbiamo parlato richiedono un investimento, con persone dedicate che validino e implementino le scelte fatte nel tempo
Questo presenta moltissime opportunità di crescita!
Sul lungo termine, è costoso risolvere gli stessi problemi in ogni team, quindi abbiamo bisogno di astrarre, per risolverli una sola volta e scalare.
Ci si può specializzare in diversi ruoli
UX Engineer
Staff Engineer
(Tech Lead, Principal)
Web Architect
astraggono a basso livello la miglior esperienza utente
hanno esperienza di specifica, collaborano con gli architect per validare scelte e definire una path
definiscono l'architettura, la divisione in team, l'ownership, la strategia e la comunicazione fra parti
Per ricapitolare
Scalare il front-end all'aumentare della dimensione di un business, porta innumerevoli sfide
Non è mai una questione solo di tecnologia, ma anche di user e dev experience
Le scelte che facciamo hanno un impatto diretto sulla struttura organizzativa, i layer di management e i processi
Le opportunità di crescita sono moltissime!
qual è la vostra esperienza in merito? parliamone!
Domande?
HOW TO DEAL WITH FRONT-END AT SCALE
By Luca Colonnello
HOW TO DEAL WITH FRONT-END AT SCALE
HOW TO DEAL WITH FRONT-END AT SCALE
