Le terme développeur full-stack est de plus en plus utilisé ces derniers temps. En particulier dans les discussions sur la structure de l'équipe, les exigences de recrutement ou pour déduire la pure génialité d'un individu.

Quand je vois ce genre d'énoncé sur un CV ou que j'entends quelqu'un se décrire comme full-stack, un certain nombre de questions me viennent à l'esprit :

• Qu'entendez-vous par développement full-stack ?
• Sur quel stack revendiquez-vous la maîtrise ?
• Quelle est l'étendue de vos connaissances pour chacun des éléments ? À quel point doit-il être rempli ?

• Le développeur full-stack est-il une réalité ? Existent-ils vraiment ?
• S'ils existent, pourquoi sont-ils utiles ?
• Le full-stack est-il une autre façon de dire touche-à-tout, maître de rien ?

Arrière plan

Avant d'entrer dans les détails, il est utile de définir ce que nous visons à développer et à livrer.

Prétendre être un développeur full-stack pour un PoC exécuté sur votre ordinateur portable est sans doute une description juste puisque vous êtes la seule personne à développer chaque partie de cette solution. L'échelle est très petite et l'impact d'une mauvaise conception ou d'un développement est très limité. Fondamentalement, vous prouvez qu'un concept ne fournit pas de service, tant qu'il peut fonctionner pendant l'heure de démonstration au CIO, tout va bien.

Si nous définissons la solution comme étant un système de production gérant des données client en direct et produisant des informations/données générant de la valeur commerciale, la situation est différente et l'impact des erreurs de codage ou des mauvaises pratiques est beaucoup plus élevé.

Pour les besoins de cet article, nous considérerons un système traitant de grandes quantités (10 s de Go par jour) de données client réelles (y compris les PII) et fournissant des services commerciaux clés avec au moins 2 9 s de disponibilité.

Pourquoi les développeurs full-stack sont-ils précieux ?

Si l'on met de côté l'existence de ces personnes, les avantages qu'elles procurent sont évidents. Ils sont capables de concevoir, de construire et d'exécuter une solution sans aucun support externe ; cela signifie que tous ces ateliers de conception chronophages et sujets aux erreurs, les intégrations de composants, les cycles de test et les transferts d'opérations sont largement éliminés. Il n'est pas nécessaire de planifier une réunion, ou pire une série de réunions, entre la sécurité, la plate-forme, la base de données, les opérations, … les PME car vous êtes en mesure de concevoir, de construire et d'exécuter la solution. Un petit nombre de ces développeurs de type dieu (petit g) sont capables de fournir le travail d'une grande équipe interfonctionnelle et, en raison de l'élimination des frais généraux liés aux transferts, la livraison est également beaucoup plus rapide et moins sujette aux erreurs.

Alors, sur la base de ces avantages évidents, pourquoi n'y a-t-il pas plus d'équipes composées de ces personnes dans toutes les organisations informatiques ? Pourquoi les entreprises ne recrutent-elles pas et ne forment-elles pas activement pour constituer ces équipes de ninjas ? Est-ce parce que les équivalents de développement de Batman ou de Tony Stark n'existent pas vraiment ?

Pour répondre à ces questions, nous devons regarder à quoi ressemble une pile (très) simplifiée.

Pile simplifiée

Je laisse de côté l'infrastructure de la plate-forme à des fins de simplification.

En regardant les éléments ci-dessus, il est évident qu'être un expert dans chaque couche va être difficile. Cependant, en supposant que je n'ai pas besoin de TOUT connaître dans chaque couche, puis-je réduire les connaissances requises et être toujours considéré comme une pile complète ? En prenant l'application frontale comme exemple de domaine, nous pourrions facilement supprimer Android et iOS et nous concentrer uniquement sur un canal Web et peut-être affiner encore plus et dire que c'est limité à React, comment cela aide-t-il ?

Sur la base de notre portée réduite, que dois-je savoir sur les applications Web React ?

Tout d'abord, vous devrez comprendre le fonctionnement des applications à page unique, en particulier les principes de base nécessaires pour créer, déboguer et exécuter une application Web et les outils associés, par exemple npm, webpack, gestion de contenu, réagir aux devtools, directives UX, …

Vous devrez également être très familier avec les fonctionnalités fournies par des tiers, par exemple l'interface utilisateur matérielle, redux, bootstrap, … et une solution de gestion de packages telle que npm (y compris la gestion des vulnérabilités de sécurité - généralement une considération DevOps, voir les notes ultérieures).

Qu'en est-il des performances, par exemple le temps de la première peinture de contenu, le temps d'interactivité, le temps de blocage, … Dois-je adopter une architecture d'application Web progressive et / ou des travailleurs de service pour m'aider ? Vous devrez comprendre les facteurs de performance et comment les différents modèles de base peuvent aider à utiliser des outils pour soutenir l'analyse, par exemple React DevTools ou Lighthouse.

L'accessibilité est un must pour toutes les applications, que l'application soit livrée en interne ou en externe. Comment puis-je garantir la conformité aux directives des WCAG ?

En résumé, juste dans la couche Front-End, il y a beaucoup à savoir et sans doute cela le garde léger. Les couches restantes ne sont pas différentes et dans de nombreux cas, la complexité augmente. Et pour aggraver les choses, les modèles et principes architecturaux, les meilleures pratiques et les cadres NE SE RECOUVRENT PAS .

Donc, en supposant que j'ai réussi à entasser les modèles, les normes, les meilleures pratiques et les compétences pratiques pour chaque couche dans ma tête sans que cela explose, que dois-je savoir d'autre ? Des capacités de support sont-elles requises ?

Capacités de soutien

Aux côtés de la pile technologique, un certain nombre de capacités de support sont nécessaires pour concevoir, construire, fournir et exécuter tous les composants de la solution.

Architecture & Ingénierie SW

Ensemble de compétences de base pour soutenir la conception architecturale à travers les couches créant une bonne mise en œuvre dans n'importe quel langage / framework

• SOLIDE (Responsabilité unique, Ouvert/Fermé, Substitution, Ségrégation d'interface, Inversion de dépendance)
• 'ilities' réutilisabilité, maintenabilité, portabilité, extensibilité, …
• Mise à l'échelle horizontale et verticale
• Structure de codage
• Enregistrement
• Revues de code
• …

Chacune des couches et des composants de chaque couche (en ignorant le Front-End du point de vue du canal Web, car il est soit implémenté par le navigateur, soit généralement hors de notre contrôle puisqu'il s'agit du côté client) dans la pile simplifiée ci-dessus nécessite une attention particulière du point de vue de la sécurité. par exemple

• API : TLS, DDoS, authentification et autorisation, CORs, politique de sécurité des contenus, …
• Microservices : TLS (incl MA), contrôles d'accès, gestion des secrets, validation des entrées utilisateurs, …
• Données : contrôles d'accès, chiffrement au repos, gestion des clés, groupes et sous-réseaux de sécurité réseau, …
• Plate-forme (supplémentaire) : sécurité du réseau, configurations de composants fixes, par exemple ChefInspec

Tous les développeurs ont besoin de compétences de test de base, il n'y a aucune excuse pour ne pas pouvoir tester vos propres fonctionnalités. Et dans un environnement full-stack, cela signifie chaque composant du diagramme ci-dessus.

Comprendre et être capable d'appliquer les différents types et phases de test (sans noter vos propres devoirs):

• Fonctionnel et non fonctionnel
• Boîte noire contre boîte blanche
• Unité, intégration, système, acceptation utilisateur, régression, smoke, …

Développer et maintenir des pipelines d'intégration continue et de déploiement continu

Les catalyseurs de base pour CICD sont souvent créés par une équipe centralisée / dédiée, mais tout le monde devrait être en mesure de mettre à jour et de maintenir les pipelines à tout le moins. (Oui, je sais ; si vous avez une équipe DevOps, vous ne faites pas de DevOps, mais de nombreuses organisations le font)

Utiliser des outils tels que :

• Jenkins, TravisCI, Spinnaker
• GitHub, Bitbucket
• Sonarqube
• Zaproxy
• Veracode, Snyk
• Docker, Ancre, Port
• …

Si nous ignorons l'approche "vous le construisez, vous l'exécutez", les exigences d'un développeur full-stack concernant les opérations sont considérablement simplifiées

L'accent doit être mis sur la création de votre application pour qu'elle soit opérationnelle. Y compris tous les hooks de diagnostic requis, les journaux d'événements et un runbook de sorte qu'une équipe d'exécution puisse trier et potentiellement résoudre les problèmes sans avoir besoin de faire appel à l'aide de l'équipe de développement

Bien sûr, la responsabilité des capacités ci-dessus est susceptible d'être basée sur la façon dont votre organisation est gérée - peut-être que le développement est strictement un test unitaire uniquement, ou que tous les tests sont au sein de l'équipe Scrum à l'exception des tests de sécurité. Mais si vous êtes en mesure de prendre en charge le développement d'API et la gestion du pipeline CICD sans avoir besoin de l'aide d'autres personnes, cela vous fera gagner beaucoup de temps.

Comme pour les couches de la pile technologique, l'étendue des capacités de prise en charge requises pour revendiquer le statut de pile complète est vaste.

Conclusion

Je crois que le véritable développeur full-stack est un mythe (en grande partie) et ce depuis que la pile est allée au-delà de l'exécution de l'assembleur sur un 6502 dans les années 1980. Ne vous trompez pas en pensant que le fait d'avoir un front-end opérationnel et de parler à quelques API écrites dans Node s'exécutant sur le nœud K8 signifie que vous êtes un développeur full-stack.

Ces personnes sont mythiques non seulement en raison de la profondeur des connaissances et de l'expérience qu'elles doivent posséder dans différents domaines techniques, mais aussi parce que cette portée ne cesse d'augmenter - chaque année, il y a d'énormes développements dans les technologies et les modèles dans chacun des domaines, en suivant à ce jour est très, très difficile.

De plus, ces personnes vont généralement demander plus d'argent que la plupart des organisations informatiques ne peuvent se permettre de les payer, mais si elles sont vraiment complètes, elles en valent la peine, comme le dit l'annonce.

Je propose que le mieux que vous puissiez espérer atteindre est la maîtrise de votre domaine choisi (une couche spécifique avec une pile technologique limitée dans cette couche) et, au mieux, la compétence et la conscience de votre manque de connaissances dans d'autres domaines.

Une meilleure façon pour une équipe de réussir n'est pas d'essayer de recruter ou de former des développeurs full stack, mais plutôt de créer des domaines, par exemple front-end, back-end, base de données, etc. et de travailler vers des connaissances de niveau ninja dans un domaine donné (encore une fois la pile sera limitée) avec des connaissances qui se chevauchent/croisent dans les autres domaines avec des interfaces, des normes, des meilleures pratiques et des cadres très clairs pour soutenir un développement de haute qualité. Si les individus sont capables de couvrir plusieurs domaines au niveau expert, c'est très bien, mais d'après mon expérience, c'est vraiment l'exception.

Commentaire bonus :

Que devez-vous savoir pour avoir "plus" de succès en tant que développeur de science des données (notez l'utilisation du mot développeur ici plutôt que du terme scientifique des données - je suppose que vous êtes déjà un bon scientifique des données ? Et si ce n'est pas le cas, je je ne peux pas t'aider !). Si nous définissons ce développeur comme quelqu'un qui peut se développer dans chacun de ces domaines mais qui est un expert de la partie Data Science*, c'est-à-dire mon objectif réduit ci-dessus, l'industrialisation de la pile plus large est quelque chose qu'un ingénieur en apprentissage machine ferait… mais cette discussion est pour une autre fois.

* dans notre pile simplifiée, nous pouvons dire que le modèle va dans le bit des microservices… un peu