Il termine sviluppatore full-stack viene utilizzato sempre più frequentemente di recente. In particolare nelle discussioni sulla struttura del team, sui requisiti per il reclutamento o per dedurre la pura bellezza di un individuo.

Quando vedo questo tipo di dichiarazione su un CV o sento qualcuno che si descrive come full-stack, mi vengono in mente una serie di domande:

• Cosa intendi per sviluppo full-stack?
• Su quale stack rivendichi la padronanza?
• Quanto è ampia la tua conoscenza per ciascuno degli elementi? Quanto deve essere pieno?

• Lo sviluppatore full-stack è una cosa reale? Esistono davvero?
• Se esistono perché sono utili?
• Full-stack è un altro modo per dire tuttofare, maestro di nessuno?

Sfondo

Prima di entrare nei dettagli vale la pena definire ciò che miriamo a sviluppare e fornire.

Affermare di essere uno sviluppatore full-stack per un PoC in esecuzione sul tuo laptop è probabilmente una descrizione corretta poiché sei l'unica persona che sviluppa ogni parte di quella soluzione. La scala è molto piccola e l'impatto di una cattiva progettazione o sviluppo è molto limitato. Fondamentalmente stai dimostrando un concetto che non fornisce un servizio, fintanto che può funzionare per l'ora di dimostrazione al CIO va bene.

Se definiamo la soluzione come un sistema di produzione che gestisce i dati dei clienti in tempo reale e produce approfondimenti/dati che guidano la generazione di valore aziendale, la situazione è diversa e l'impatto degli errori di codifica o delle cattive pratiche è molto più elevato.

Ai fini di questo post, prenderemo in considerazione un sistema che elabora grandi quantità (10 GB al giorno) di dati reali dei clienti (comprese le PII) e fornisce servizi aziendali chiave con almeno 2 9 di disponibilità.

Perché gli sviluppatori full-stack sono preziosi?

Mettendo da parte l'esistenza di queste persone, i benefici che forniscono sono evidenti. Sono in grado di progettare, costruire ed eseguire una soluzione senza alcun supporto esterno; ciò significa che tutti i workshop di progettazione, le integrazioni dei componenti, i cicli di test e le consegne delle operazioni che richiedono tempo e sono soggetti a errori vengono in gran parte eliminati. Non è necessario programmare una riunione, o peggio una serie di riunioni, tra la sicurezza, la piattaforma, il DB, le operazioni, … PMI perché sei in grado di progettare, costruire ed eseguire la soluzione. Un piccolo numero di questi sviluppatori simili a dio (g minuscola) è in grado di fornire il lavoro di un grande team interfunzionale e, grazie all'eliminazione del sovraccarico delle consegne, la consegna è anche molto più veloce e meno soggetta a errori.

Quindi, sulla base di questi chiari vantaggi, perché non ci sono più team composti da queste persone in tutte le organizzazioni IT? Perché le aziende non stanno reclutando e formando attivamente per costruire questi team ninja? È perché gli equivalenti di sviluppo di Batman o Tony Stark non esistono davvero?

Per rispondere a queste domande, dobbiamo osservare come appare uno stack (molto) semplificato.

Pila semplificata

Lascio fuori l'infrastruttura della piattaforma a scopo di semplificazione.

Guardando gli elementi di cui sopra è ovvio che essere un esperto in ogni livello sarà una sfida. Tuttavia, supponendo che non ho bisogno di sapere TUTTO in ogni livello, posso ridurre le conoscenze richieste ed essere comunque considerato full-stack? Prendendo l'app front-end come dominio di esempio, potremmo facilmente rimuovere Android e iOS e concentrarci solo su un canale web e magari perfezionare ulteriormente e dire che è limitato a React, come può essere d'aiuto?

Sulla base del nostro ambito ridotto, cosa devo sapere sulle app Web di React?

Bene, in primo luogo dovrai capire come funzionano le app a pagina singola, in particolare i principi fondamentali richiesti per creare, eseguire il debug ed eseguire un'app Web e gli strumenti associati, ad esempio npm, webpack, gestione dei contenuti, react devtools, linee guida UX, ...

Dovrai anche avere molta familiarità con le funzionalità fornite da terze parti, ad esempio UI materiale, redux, bootstrap, ... e una soluzione di gestione dei pacchetti come npm (inclusa la gestione delle vulnerabilità di sicurezza, in genere una considerazione DevOps, vedi note successive).

Che dire delle prestazioni, ad esempio il tempo per la prima pittura di contenuto, il tempo per l'interattività, il tempo di blocco, ... Dovrei adottare un'architettura di app Web progressiva e / o addetti ai servizi per aiutare? Dovrai comprendere i fattori di prestazione e in che modo i vari modelli di base possono aiutare a utilizzare gli strumenti per supportare l'analisi, ad esempio React DevTools o Lighthouse.

L'accessibilità è un must per tutte le applicazioni, indipendentemente dal fatto che l'app sia fornita internamente o esternamente. Come posso garantire la conformità alle linee guida WCAG?

In sintesi, solo nel livello Front-End c'è molto da sapere e probabilmente questo lo mantiene leggero. I livelli rimanenti non sono diversi e in molti casi la complessità aumenta. E a peggiorare le cose, i modelli e i principi dell'architettura, le migliori pratiche e i framework NON SI SOVRAPPONGONO .

Quindi, supponendo che io sia riuscito a stipare nella mia testa gli schemi, gli standard, le migliori pratiche e le abilità pratiche per ogni livello senza che esploda, cos'altro devo sapere? Sono richieste funzionalità di supporto?

Capacità di supporto

Accanto allo stack tecnologico ci sono una serie di funzionalità di supporto necessarie per progettare, costruire, fornire ed eseguire tutti i componenti della soluzione.

Architettura e Ingegneria SW

Set di competenze di base per supportare la progettazione architettonica a tutti i livelli creando una buona implementazione in qualsiasi linguaggio / framework

• SOLIDO (Responsabilità singola, Aperto/Chiuso, Sostituzione, Segregazione interfaccia, Inversione dipendenza)
• 'illities' riusabilità, manutenibilità, portabilità, estensibilità, …
• Ridimensionamento orizzontale e verticale
• Struttura di codifica
• Registrazione
• Revisioni del codice
• …

Ciascuno dei livelli e dei componenti all'interno di ogni livello (ignorando il front-end dal punto di vista del canale Web poiché è implementato dal browser o in genere fuori dal nostro controllo poiché è lato client) nello stack semplificato sopra richiede un'attenta considerazione dal punto di vista della sicurezza per esempio

• API : TLS, DDoS, autenticazione e autorizzazione, COR, politica di sicurezza dei contenuti, …
• Microservizi : TLS (incl MA), controlli di accesso, gestione dei segreti, convalida dell'input dell'utente, …
• Dati : controlli di accesso, crittografia a riposo, gestione delle chiavi, gruppi di sicurezza di rete e sottoreti,...
• Piattaforma (aggiuntiva) : sicurezza di rete, configurazioni di componenti fisse, ad esempio ChefInspec

Tutti gli sviluppatori hanno bisogno di competenze di test di base, non ci sono scuse per non essere in grado di testare le proprie funzionalità. E in un ambiente full-stack ciò significa ogni componente nel diagramma sopra.

Comprendere ed essere in grado di applicare i diversi tipi e fasi di test (senza correggere i propri compiti):

• Funzionale e non funzionale
• Scatola nera contro scatola bianca
• Unità, integrazione, sistema, accettazione dell'utente, regressione, fumo, …

Sviluppo e manutenzione di pipeline di Continuous Integration e Continuous Deployment

Gli abilitatori principali per CICD sono spesso creati da un team centralizzato/dedicato, ma tutti dovrebbero essere almeno in grado di aggiornare e mantenere le pipeline. (Sì, lo so; se hai un team DevOps non stai facendo DevOps ma molte organizzazioni lo fanno)

Utilizzando strumenti quali:

• Jenkins, TravisCI, Spinnaker
• GitHub, Bitbucket
• Sonarqube
• Zaproxy
• Veracode, Snyk
• Docker, Ancora, Porto
• …

Se ignoriamo l'approccio "lo costruisci, lo esegui", i requisiti per uno sviluppatore full-stack sulle operazioni vengono semplificati in modo significativo

L'attenzione deve essere rivolta alla creazione dell'applicazione affinché sia ​​operativa. Compresi tutti gli hook diagnostici richiesti, i registri degli eventi e un runbook in modo tale che un team di esecuzione sia in grado di valutare e potenzialmente risolvere i problemi senza dover ricorrere all'aiuto del team di sviluppo

Ovviamente, è probabile che la responsabilità per le capacità di cui sopra si basi su come viene gestita la tua organizzazione, forse lo sviluppo è strettamente solo unit test o tutti i test sono all'interno del team di scrum ad eccezione dei test di sicurezza. Ma se sei in grado di occuparti dello sviluppo dell'API e della gestione della pipeline CICD senza bisogno del supporto di altri, risparmierai molto tempo.

Come per i livelli dello stack tecnologico, l'ambito delle capacità di supporto necessarie per rivendicare lo stato di stack completo è vasto.

Conclusione

Credo che il vero sviluppatore full-stack sia un mito (in gran parte) e lo è stato sin da quando lo stack è andato oltre l'esecuzione dell'assembler su un 6502 negli anni '80. Non illuderti nel pensare che avere un front-end attivo e funzionante parlando con alcune API scritte in Node in esecuzione sul nodo K8 significhi che sei uno sviluppatore full-stack.

Questi individui sono mitici non solo per la profondità della conoscenza e dell'esperienza che devono avere in diversi domini tecnici, ma anche perché questa portata è in continua crescita: ogni anno ci sono enormi sviluppi nelle tecnologie e nei modelli in ciascuno dei domini, tenendo il passo fino ad oggi è molto, molto difficile.

Inoltre, queste persone generalmente chiederanno più soldi di quanto la maggior parte delle organizzazioni IT possa permettersi di pagarle, ma se sono veramente full-stack ne valgono la pena, come dice l'annuncio.

Propongo che il meglio che puoi sperare di ottenere sia la padronanza del dominio prescelto (un livello specifico con uno stack tecnologico limitato all'interno di quel livello) e, nella migliore delle ipotesi, competenza e consapevolezza della tua mancanza di conoscenza in altre aree.

Un modo migliore per un team di avere successo non è tentare di reclutare o addestrare sviluppatori full stack, ma invece creare domini, ad esempio front-end, back-end, database, ecc. lo stack sarà limitato) con conoscenze sovrapposte/incrociate negli altri domini con interfacce, standard, best practice e framework molto chiari per supportare uno sviluppo di alta qualità. Se le persone sono in grado di coprire più domini a livello di esperti, è fantastico, ma nella mia esperienza, questa è davvero l'eccezione.

Commento bonus:

Cosa devi sapere per avere "più" successo come sviluppatore di data science (nota l'uso della parola sviluppatore piuttosto che del termine data scientist - presumo che tu sia già un bravo data scientist? E se non lo sei, io lì non posso aiutarti!). Se definiamo questo sviluppatore come qualcuno che può svilupparsi in ciascuna di queste aree ma è un esperto nella parte Data Science* cioè il mio obiettivo ridotto sopra, l'industrializzazione dello stack più ampio è qualcosa che farebbe un Machine Learning Engineer... ma quella discussione è per un'altra volta.

*nel nostro stack semplificato, possiamo dire che il modello va nella parte dei microservizi... più o meno