Le rôle du développeur Full Stack dans les grands projets

Il y a un peu moins de deux décennies, les choses étaient simples. Les développeurs de logiciels étaient principalement engagés dans le développement de logiciels de bout en bout. Il n’y avait pas de distinction majeure entre les personnes qui créent l’interface utilisateur et celles qui développent le backend. La plupart des applications étaient soit des monolithes de bureau, soit des «clients» de bureau qui communiquaient avec une sorte de serveur principal, sur le réseau:

Dans les deux cas, les premiers outils de développement fournissaient suffisamment de blocs de construction pour que les développeurs puissent tout créer dans le même projet. Cela a abouti à des applications homogènes, mais ennuyeuses et peu attrayantes. À cette époque, le Web était, pour la plupart, un tas de pages statiques, liées les unes aux autres. À quelques exceptions près, la plupart d’entre eux ressemblaient à l’aspect et à la convivialité de leurs homologues Windows en blocs.

Quelques années plus tard, au début et au milieu des années 2000, la révolution du Web 2.0 a tout balayé. Plutôt que de rester des monolithes à usage unique, les applications logicielles se sont transformées en «services» distribués. Le modèle traditionnel d’installation de centaines de mégaoctets sur un ordinateur a été remplacé par la saisie de l’URL de l’application Web préférée de l’une dans un navigateur Web. Avec le temps, la pertinence du système d’exploitation sous-jacent a diminué. En un peu moins d’une décennie, le navigateur est devenu le système d’exploitation – pour beaucoup, la seule et unique fenêtre restée ouverte à tout moment.

Le Web 2.0, et l’incursion suivante dans le mobile, ont forcé des changements importants sur la manière dont la nouvelle vague d’applications logicielles était censée être construite. Pour une fois, le développement backend et frontend sont devenus des disciplines distinctes, chacune nécessitant un ensemble différent de compétences et d’expertises. En fait, ces dernières années, le fossé entre le frontend et le backend est devenu si énorme qu’une nouvelle discipline est arrivée, destinée à recoller ces éléments – le rôle du développeur full stack.

Idées fausses

Si vous regardez les offres d’emploi de nos jours, il semble que presque tout le monde recherche des développeurs capables de travailler sur tous les aspects d’un projet. De nombreuses entreprises appellent cela une position «full stack», et en fait, de nombreuses organisations ont déjà ouvert de telles positions «full stack» dans leurs équipes. Je trouve que l’idée d’un développeur «full stack» est un génie du «savoir-tout», imparfaite, et j’ose croire que relativement peu d’organisations ont réussi à élever le nouveau rôle à son plein potentiel. Cet article tente de faire la lumière sur l’endroit où le développeur full stack devrait idéalement rester au sein d’une équipe, dans l’espoir d’aider à dissoudre ces idées fausses.

Il y a deux idées fausses très contradictoires qui sont balancées quand il s’agit de définir ce qu’est un développeur full stack, et la full stack est censée faire:

Le développeur full stack sait un peu de tout, donc notre entreprise économisera sur les ressources humaines en embauchant quelques-uns d’entre eux.

ou

Le développeur full stack sait un peu de tout, mais rien de particulier. Un développeur full stack ne serait qu’un fardeau pour notre équipe. Elle ne pourrait jamais entrer dans le niveau de détail, comme le ferait un frontend ou un backend.

Ni l’un ni l’autre n’est faux à 100%, mais ni l’un ni l’autre n’est correct non plus. Un développeur full stack n’est pas un petit génie, qui pourrait par magie remplacer une équipe d’experts en backend et frontend. Non. Bien qu’un développeur full stack soit censé comprendre les deux mondes, son rôle n’est pas de remplacer, mais d’aider à rapprocher ces deux groupes. En fait, un bon développeur full-stack est un peu comme le bassiste d’un groupe de rock:

Full Stack = Bass Player?!?

Jouer de la basse dans un groupe de rock est un rôle souvent sous-estimé, mais incroyablement important. Contrairement à la chanteuse ou au guitariste, la bassiste n’accorde guère de crédit à sa performance. À l’exception de la musique jazz et funk, la bassiste a rarement une heure de grande écoute seule. Elle ne sortira pas toujours un solo à couper le souffle, comme le ferait la guitare principale. Elle n’engagera pas toujours les fans, comme seul le chanteur pouvait le faire. Pourtant, un bon bassiste sera toujours là, collant tout le groupe ensemble.

“Un bassiste est un peu comme le mortier entre les briques.” (David Elefson, Megadeth)

Avez-vous déjà vu un bon groupe de rock avec un mauvais bassiste? Ou pire, un groupe de rock qui se respecte sans aucun bassiste? Non? Eh bien, il y a quelques bonnes raisons à cela:

Tout d’abord, il y a un énorme écart de spectre sonore entre la batterie dans le bas de gamme et les guitares et les voix aigus dans l’autre. Cette lacune est généralement comblée par la basse. Sortir la basse de l’équation, laisse un air superficiel, à gauche de «l’âme et l’esprit». Vous pouvez toujours l’écouter, mais vous aurez toujours l’impression que quelque chose manque.

Avoir un bassiste expérimenté dans le groupe est tout aussi important pour les autres camarades du groupe que pour le public. L’une des choses les plus difficiles à jouer dans un groupe est de jouer en accord et en synchronisation avec les autres. C’est là que le rôle du bassiste en tant que coordinateur et plaque tournante entre les joueurs est si important. Elle garde le tempo et le rythme fixés par le batteur à tout moment, établissant une base de la mélodie principale, qui reste à peu près la même tout au long de la chanson. Cela permet au guitariste de réussir un beau solo, sans craindre que le son ne se détache.

Retour à l’équipe

Une équipe de logiciels de nos jours, ressemble assez au groupe de rock que j’ai décrit jusqu’à présent. Vous avez généralement des développeurs backend et frontend purs, couvrant leur propre spectre de tâches. Si le projet en cours est bien spécifié, les deux parties s’accordent généralement sur une API et continuent de faire ce qu’elles font de mieux, partageant peu de préoccupations quant à la façon dont l’autre partie fait les choses.

Comme nous le savons tous, très peu de choses dans la vie fonctionnent dans leur état idéal. La plupart du temps, les développeurs passent à clarifier les malentendus dans leur communication. Ils font cela lors de longues réunions. Si vous avez participé à une telle réunion, vous savez à quel point un responsable du frontend paierait peu de respect à vos propositions détaillées pour accélérer le backend. Soyons honnêtes, quand il s’agit d’expliquer les problèmes des utilisateurs du frontend, c’est à votre tour de commencer à regarder votre téléphone. C’est juste la réalité. Le plus souvent, les visions des deux parties s’écartent, et la seule façon de les remettre sur les rails est de multiplier les réunions et les efforts de refactorisation.

C’est là que l’introduction d’un développeur full stack dans l’équipe peut être un énorme coup de pouce pour la productivité de l’équipe. Pas nécessairement en termes de mise sur le marché de nouvelles fonctionnalités, mais davantage en termes de réduction des frictions d’équipe et de réduction des efforts de refactorisation.

Le développeur de la pile complète peut comprendre les préoccupations des deux côtés et les traduire en code qui prend l’entrée d’un côté et facilite le traitement de l’autre. Dans les grands projets, cela implique généralement la création d’une fine couche d’abstraction située entre le frontend et le backend. Cette couche, également appelée «middleware», devrait masquer les détails d’implémentation du frontend et du backend et fournir un flux de données transparent d’un bout à l’autre.

Là où le développement d’un middleware était traditionnellement supposé utiliser la pile de technologies backend, j’ai constaté une évolution vers une réduction encore plus poussée de l’écart. Ce n’est pas une surprise de voir une pile mixte sur le serveur, où le backend principal pourrait être basé sur Java, avec un middleware assis à l’avant, basé sur NodeJS. Pour les grands projets logiciels, réussir un tel exploit peut avoir pour effet de faire monter en flèche le projet ou de le ramener sur terre, s’il est mal fait. C’est un endroit où le fait d’avoir un membre de l’équipe qui maîtrise l’ensemble de la pile peut faire une énorme différence.

Pas seulement ça. Les développeurs full stack peuvent être les moteurs du développement de nouvelles fonctionnalités. Bien que l’on puisse difficilement développer une nouvelle fonctionnalité sur l’ensemble de la pile seule, il est logique de laisser les développeurs de pile complète construire un échafaudage, sur lequel les développeurs backend et frontend pourront travailler plus tard. Encore une fois, cela peut économiser du temps et des efforts de communication dès le début, ainsi que des efforts de refactorisation plus tard dans le projet.

Comme vous le voyez, le rôle d’un développeur full stack dans un grand projet est loin d’être l’expert ou le petit génie qui peut tout faire. Semblable à un bassiste dans un groupe de rock, le rôle du développeur full stack est bien plus celui d’un communicateur et coordinateur entre frontend et backend. Il ne vise pas à remplacer l’un de ces rôles dans un avenir proche, mais plutôt à les soutenir et à construire des ponts entre eux. J’espère que tout cela a du sens pour vous aussi, et vous en tiendrez compte la prochaine fois que votre organisation décidera de faire participer un développeur full stack.

Clause de non-responsabilité: je suis à la fois un développeur full stack et un bassiste passionné ?

Ce message apparaît également sur mon blog