Il ruolo dello sviluppatore full stack nei grandi progetti

Poco meno di due decenni fa, le cose erano semplici. Gli sviluppatori di software erano principalmente impegnati nello sviluppo di software end-to-end. Non c’era alcuna distinzione importante tra le persone che creavano l’interfaccia utente e quelle che sviluppavano il backend. La maggior parte delle applicazioni erano monoliti desktop o “client” desktop che comunicavano con un qualche tipo di backend del server, sulla rete:

In entrambi i casi, i primi strumenti di sviluppo fornivano elementi costitutivi sufficienti per consentire agli sviluppatori di creare tutto nell’ambito dello stesso progetto. Ciò ha prodotto applicazioni omogenee, ma noiose e dall’aspetto poco attraente. A quei tempi, il Web era, per la maggior parte, un mucchio di pagine statiche, collegate tra loro. Con alcune eccentriche eccezioni, la maggior parte di loro assomigliava all’aspetto delle loro controparti Windows a blocchi.

Alcuni anni dopo, all’inizio e alla metà degli anni 2000, è arrivata la rivoluzione del Web 2.0, che ha spazzato via tutto. Piuttosto che rimanere monoliti monouso, le applicazioni software si sono trasformate in “servizi” distribuiti. Il modello tradizionale di installazione di centinaia di megabyte sul proprio computer, è stato sostituito digitando l’URL della propria app web preferita in un browser web. Con il tempo, la rilevanza del sistema operativo sottostante è diminuita. In poco meno di un decennio, il browser è diventato il sistema operativo, per molti l’unica finestra tenuta sempre aperta.

Il Web 2.0 e la successiva incursione nel settore dei dispositivi mobili hanno imposto cambiamenti significativi nel modo in cui doveva essere costruita la nuova ondata di applicazioni software. Per una volta, lo sviluppo backend e frontend sono diventati discipline separate, ognuna delle quali richiedeva un diverso insieme di abilità e competenze. In effetti, negli ultimi anni, il divario tra frontend e backend è diventato così enorme che è arrivata una nuova disciplina, intesa a incollare nuovamente quei pezzi: il ruolo dello sviluppatore dello stack completo.

Idee sbagliate

Se guardi gli annunci di lavoro al giorno d’oggi, sembra che quasi tutti stiano cercando sviluppatori che possano lavorare su tutti gli aspetti di un progetto. Molte aziende chiamano questa posizione una posizione “full stack” e in effetti molte organizzazioni hanno già aperto tali posizioni “full stack” nei loro team. Trovo che questa idea di uno sviluppatore “full stack” sia un mago “sa tutto”, imperfetta e oso credere che relativamente poche organizzazioni siano riuscite a portare il nuovo ruolo al suo pieno potenziale. Questo post cerca di far luce su dove idealmente lo sviluppatore full stack dovrebbe stare all’interno di un team, sperando di aiutare a dissolvere questi malintesi.

Ci sono due idee sbagliate molto contraddittorie che vengono sballottate, quando si tratta di definire cosa sia uno sviluppatore full stack, e lo stack completo dovrebbe fare:

Lo sviluppatore full stack sa un po ‘di tutto, quindi la nostra azienda risparmierà sulle risorse umane, assumendone alcuni.

o

Lo sviluppatore full stack sa un po ‘di tutto, ma niente in particolare. Uno sviluppatore full stack sarebbe solo un peso per il nostro team. Non sarebbe mai stata in grado di approfondire il livello di dettaglio, come farebbe un frontend o un ragazzo di backend.

Nessuno di questi è sbagliato al 100%, ma nessuno dei due è corretto. Uno sviluppatore full stack non è un mago, che potrebbe sostituire magicamente un team di esperti di backend e frontend. No. Anche se uno sviluppatore full stack dovrebbe comprendere entrambi i mondi, il suo ruolo non è quello di sostituire, ma di aiutare ad avvicinare questi due gruppi. In effetti, un buon sviluppatore full-stack è un po ‘come il bassista di una rock band:

Stack completo = Bassista?!?

Suonare il basso in una rock band è un ruolo spesso sottovalutato, ma incredibilmente importante. A differenza del cantante o del chitarrista, il bassista si prende poco credito per la sua performance. Con l’eccezione del jazz e della musica funk, il bassista raramente ha un ottimo momento da solo. Non tirerà sempre fuori un assolo mozzafiato, come farebbe la chitarra solista. Inoltre, non coinvolgerà sempre i fan, come solo il cantante potrebbe fare. Tuttavia, un bravo bassista sarà sempre lì, incollando l’intera band insieme.

“Un bassista è un po ‘come il mortaio tra i mattoni.” (David Elefson, Megadeth)

Hai mai visto una buona rock band con un cattivo bassista? O peggio, una rock band che si rispetti e senza bassista? No? Bene, ci sono alcune buone ragioni per questo:

Prima di tutto, c’è un enorme divario nello spettro sonoro tra la batteria nella fascia bassa e le chitarre e le voci acute nell’altra. Questo spazio è solitamente riempito dal basso. Togliendo il basso dall’equazione, lascia una melodia superficiale, a sinistra di “anima e spirito”. Puoi ancora ascoltarlo, ma ti sembrerà sempre che manchi qualcosa.

Avere un bassista esperto nella band, però, è altrettanto importante per gli altri compagni di band, come lo è per il pubblico. Una delle cose più difficili nel suonare in una band è suonare in sintonia e sincronizzarsi con gli altri. È qui che il ruolo del bassista come coordinatore e hub tra i musicisti è così importante. Mantiene sempre il tempo e il ritmo impostati dal batterista, ponendo le basi della melodia principale, che rimane praticamente la stessa per tutta la canzone. Ciò consente al chitarrista di eseguire un bellissimo assolo, senza il timore che il suono si stacchi.

Torna al team

Un team di software oggigiorno sembra abbastanza simile al gruppo rock che ho descritto finora. Di solito hai sviluppatori puri di backend e frontend, che coprono i propri spettri di attività. Se il progetto in questione è ben specificato, in genere entrambe le parti concordano su un’API e continuano a fare ciò che sanno fare meglio, condividendo poche preoccupazioni su come l’altra parte sta facendo le cose.

Come tutti sappiamo, però, pochissime cose nella vita funzionano nel loro stato ideale. La maggior parte del tempo, gli sviluppatori passano a eliminare i malintesi nella loro comunicazione. Lo fanno in riunioni lunghe. Se sei stato in una riunione del genere, sai quanto poco rispetto un ragazzo di frontend pagherebbe alle tue proposte dettagliate per accelerare il backend. Siamo onesti però, quando si tratta di ragazzi frontend che spiegano i loro problemi, è il tuo turno di iniziare a guardare il tuo telefono. Questa è solo la realtà. Il più delle volte, le visioni delle due parti si discostano e l’unico modo per riportarle in carreggiata sono più incontri e sforzi di refactoring.

È qui che l’introduzione di uno sviluppatore full stack nel team può essere un enorme impulso per la produttività del team. Non necessariamente in termini di introduzione di nuove funzionalità sul mercato, ma più in termini di riduzione dell’attrito del team e riduzione degli sforzi di refactoring.

Lo sviluppatore dello stack completo può comprendere le preoccupazioni di entrambe le parti e tradurle in codice che prende l’input da un lato e ne semplifica l’elaborazione per l’altro. Nei progetti di grandi dimensioni, ciò di solito comporta la creazione di un sottile strato di astrazione che si trova tra frontend e backend. Questo livello, noto anche come “middleware”, dovrebbe nascondere i dettagli di implementazione sia del frontend che del backend e fornire un flusso continuo di dati da un’estremità all’altra.

Laddove si presumeva tradizionalmente lo sviluppo di un middleware utilizzando lo stack tecnologico di backend, ho assistito a un cambiamento verso il colmare ulteriormente il divario. Non è una sorpresa vedere uno stack misto sul server, dove il backend principale potrebbe essere basato su Java, con un middleware in primo piano, basato su NodeJS. Per i progetti software di grandi dimensioni, realizzare un’impresa del genere può avere l’effetto di far salire alle stelle il progetto o di portarlo con i piedi per terra, se fatto in modo improprio. Questo è un posto in cui avere un membro del team esperto in tutto lo stack può fare un’enorme differenza.

Non solo quello. Gli sviluppatori full stack possono essere i driver dello sviluppo di nuove funzionalità. Sebbene sia difficile sviluppare una nuova funzionalità nell’intero stack da solo, ha senso lasciare che gli sviluppatori full stack costruiscano uno scaffolding, su cui gli sviluppatori di backend e frontend possono lavorare in seguito. Ancora una volta, questo può far risparmiare tempo e sforzi di comunicazione nelle prime fasi, così come sforzi di refactoring nelle fasi successive del progetto.

Come vedi, il ruolo di uno sviluppatore full stack in un grande progetto è ben lungi dall’essere l’esperto o il mago che può fare tutto. Simile a un bassista in una rock band, il ruolo dello sviluppatore full stack è molto più quello di un comunicatore e coordinatore tra frontend e backend. Non ha lo scopo di sostituire nessuno di quei ruoli nel prossimo futuro, ma piuttosto di sostenerli e costruire ponti tra di loro. Spero che tutto ciò abbia senso anche per te e lo prenderesti in considerazione la prossima volta che la tua organizzazione deciderà di coinvolgere uno sviluppatore completo.

Dichiarazione di non responsabilità: sono sia uno sviluppatore completo che un appassionato bassista 😉

Questo post appare anche nel mio blog