Prémisse

Ce qui suit est une réponse au bel article de Josh Collinsworth que vous pouvez retrouver ici.

J'ai décidé de structurer ce contenu en prenant chaque citation récapitulative qu'il fait dans son article et en répondant à chacune d'elles avec mon avis.

Cet article doit donc être considéré comme une série d’idées qui identifient une opinion personnelle. Sur les 12 citations rapportées, je me suis retrouvé d'accord avec ✅ 8 d'entre elles, en désaccord avec ❌ 3 et sans opinion sur  ? 1.

[TL;DR] Je suis généralement d'accord avec l'opinion et le point de vue de l'auteur, même si dans certains cas, la vision déformée créée par l'article m'a amené à être en désaccord avec certaines déclarations. L'analyse sur les préjugés a causé, à mon avis, tout autant de préjugés envers le monde du développement de la part de l'auteur.

J’ai l’impression de constater une diminution généralisée de la pratique du frontend. Presque partout où je regarde, je constate que son importance est minimisée et ses défis banalisés.

✅ Je suis entièrement d'accord avec cette déclaration.

Le frontend a trop longtemps été considéré comme le « petit frère » du backend, et c’est une erreur. Le frontend est la partie d'une application que l'utilisateur final voit et avec laquelle il interagit, et est donc fondamental pour le succès d'un produit. Son importance ne peut être sous-estimée, pourtant cela arrive trop souvent, et J'ai moi-même parfois considéré mon travail de développeur frontend comme « inférieur » à ce que je faisais dans le backend.

Pourquoi cela se produit-il ? De mon point de vue, je pense que c'est parce qu'au cours de la dernière décennie, le monde du développement front-end a été envahi par des frameworks et des bibliothèques qui ont rendu le travail plus simple et plus accessible à tous. Cela a conduit à répondre à de nombreux problèmes apparus dans le passé, ce qui a conduit le développement frontend à devenir « plus simple ». Cela a conduit à une dévalorisation du rôle du développeur frontend, qui est souvent considéré comme un « singe code ». Simple ne veut cependant pas dire facile, et le développeur frontend est souvent appelé à résoudre des problèmes complexes et à prendre des décisions importantes, précisément parce qu'il n'est plus censé résoudre des problèmes « simples », déjà résolus par le framework, mais plutôt pour enrichir les expériences utilisateur de manière nouvelle et innovante.

C’est comme si CSS existait dans un état quantique bizarre ; d'une manière ou d'une autre, à la fois trop complexe à utiliser et trop simple à prendre au sérieux.

✅ Là aussi, je suis d'accord.

CSS est l'un des langages les plus sous-estimés et dévalorisés dans le monde du développement Web. CSS est un langage puissant et complexe, qui permet de créer des interfaces utilisateur complexes et détaillées. Cependant, l’éloignement de la manière habituelle d’écrire du code, sa syntaxe particulière et sa logique de fonctionnement rendent souvent difficile sa maîtrise et son utilisation. CSS est un langage qui demande du temps et du dévouement pour être maîtrisé, et ce qui s'est passé avec le mouvement CSS-in-JS est un exemple clair de la façon dont la communauté a essayé de résoudre un problème qui n'existait pas en créant un nouveau, tout en ajoutant de l'abstraction à un langage déjà très complexe.

À bien des égards, CSS a un impact plus grand que tout autre langage sur l’expérience utilisateur, ce qui influence souvent directement le succès. Pourquoi, alors, son rôle est-il si minimisé ?

✅ Je suis d'accord.

Comme mentionné en réponse à la citation précédente, je pense que le problème avec CSS est dû à sa logique de fonctionnement et à sa syntaxe particulière. Le problème est qu’il est souvent perçu comme un langage « secondaire » par rapport à JavaScript, alors qu’en réalité il est un langage à part entière, avec ses règles et particularités, et nécessite un temps d’apprentissage comparable à celui d’une programmation. CSS est un langage puissant et complexe, et son rôle ne peut être sous-estimé.

La plupart du temps, personne ne dit que le frontend est moins important, ou moins réel, ou qu’il n’est pas nécessaire d’être aussi intelligent pour le faire. Mais cela semble souvent implicite.

✅ Je suis partiellement d'accord.

À vrai dire, je considère ce thème comme beaucoup plus explicite que ne le dit l'auteur. En fait, je me retrouve souvent à devoir débattre avec des gens qui considèrent le frontend comme un travail « mineur » par rapport au backend, et qui estiment que le développeur frontend ne devrait pas être un programmeur, mais un support à ceux qui font le vrai travail, le backend. Lorsqu'ils me demandent quel est mon rôle, je réponds toujours Full-Stack, car dans ma formation et ma croissance, il y a des éléments divers et différents, et les deux côtés de la médaille ont été importants et significatifs pour moi.

Je pense que la communauté doit faire davantage pour éradiquer cette mentalité. Le développeur frontend est un professionnel à tous égards, et son travail est fondamental au succès d'un produit.

Le développeur frontend est appelé à résoudre des problèmes complexes, supportés par des outils en constante évolution — ce qui augmente considérablement la charge cognitive — et à prendre des décisions importantes qui influencent directement l'expérience utilisateur, rempart d'un produit à succès.

Notre production est artistique, dans une certaine mesure, et les choses artistiques ont une longue et riche histoire d’être tragiquement dévalorisées simplement parce qu’elles semblent simples et agréables.

✅ Je suis d'accord.

Le manque de compréhension des rôles et des responsabilités joue un rôle fondamental dans notre industrie. Le développeur frontend est souvent perçu comme un « artiste », un « créatif », et son travail est dévalorisé car il n’est pas « technique » comme celui du développeur backend. C'est une erreur à deux égards.

Tout d'abord, ce n'est souvent pas le développeur frontend qui décide du design d'une application, mais le designer (UX, UI, appelez ça comme vous voulez). Le développeur frontend est appelé à traduire le design en code, et ce, de manière efficace et performante. Cela nécessite des compétences techniques et des connaissances spécifiques, qui vont bien au-delà de la simple écriture de code.

Deuxièmement, comme déjà mentionné ci-dessus, les responsabilités d'un développeur frontend vont souvent bien au-delà de la simple écriture de code. Si je modifie le code dans mon application backend, les tests automatiques remarqueront probablement les régressions plus tôt que moi. Si je modifie le code de mon application frontend, il est très probable que le seul moyen de remarquer des régressions soit de tester manuellement l'application ou d'attendre un rapport des clients finaux*. Cela rend le travail du développeur frontend beaucoup plus complexe et exigeant qu’on pourrait le penser. Sans parler de la quantité de logique métier et de gestion de l'état - toutes deux rapidement intégrées au frontend - qui rendent le rôle de plus en plus intégré à l'entreprise.

*Remarque : Je connais bien l'existence de tests de bout en bout, mais leur mise en œuvre est beaucoup plus complexe et coûteuse que les tests automatiques traditionnels, de plus leur fiabilité est souvent remise en question en raison de leurs conditions aléatoires et externes.

Le langage implique que les interfaces sont découplées du logiciel et n’en font pas réellement partie.

 ? Aucun avis à ce sujet.

La référence ici est au paradoxe selon lequel dans notre secteur il semble y avoir une différence entre Développeur et Ingénieur et qui doit nécessairement être montré comme quelque chose de plus. Je n'ai pas d'opinion sur la question, mais je reconnais qu'aujourd'hui la prolifération des titres et des bannières ne fait que brouiller les pistes par rapport à ce que chacun de nous fait réellement.

Écrire du CSS semble être considéré comme prendre des notes lors d’une réunion, avec le sexisme implicite et la dévalorisation de l’importance du preneur de notes dans la salle.

✅ Je suis d'accord.

Comme déjà mentionné précédemment dans cet article, je suis d'accord sur la dévaluation incorrecte du CSS et du monde frontend en général. De plus, dans cette partie de l’article, il est fait référence au chauvinisme présent dans notre secteur, et même si je n’en ai jamais eu une perception directe, j’en comprends la réalité et la gravité. Notre industrie est encore trop souvent un environnement hostile aux femmes, et je pense que la communauté doit faire davantage pour lutter contre cette mentalité.

Comme si le travail presque impossible consistant à prendre en charge tous les appareils, systèmes d'exploitation, tailles d'écran, navigateurs, préférences utilisateur et interfaces possibles dans le passé, le présent et le futur était si simple que nous avons inventé toute la complexité nous-mêmes, simplement parce que nous nous ennuyions.

✅ Je suis d'accord avec le sens intrinsèque de cette déclaration.

La complexité du monde d'aujourd'hui rend le rôle du développeur front-end encore plus complexe qu'il ne l'a jamais été, et lorsque les blagues front-end et les punchlines deviennent des biais, il est facile de tomber dans le piège. le piège de la dévalorisation du travail des travailleurs frontend.

Oui, en tant que groupe, nous sommes enthousiasmés par les nouveautés. Mais pourquoi cela ne nous rend-il pas curieux, adaptables ou curieux ? Pourquoi ne sommes-nous pas reconnus pour notre joie d’apprendre, au lieu d’être dénigrés pour avoir refusé de rester en place ?

❌ Je suis moins d'accord avec celui-ci.

Bien qu'il soit vrai que l'évolution du monde frontend — comme déjà mentionné précédemment — a conduit à une prolifération d'idées, d'outils et de méthodologies, le Le syndrome des objets brillants est un problème réel et répandu, en particulier dans la communauté front-end. Cela ne veut pas dire que vous ne devez pas être curieux ou adaptable, mais que vous tombez souvent dans le piège d’adopter de nouvelles technologies sans bien en comprendre les avantages et les inconvénients, et sans évaluer si elles sont réellement nécessaires ou non.

Si nos compétences sont aussi précieuses que du ruban adhésif pour combler les failles de l’organisation, pourquoi ne le sont-elles pas lors de la planification et de la prise de décision qui ont conduit à ces défauts, alors que nous pourrions potentiellement les éviter ?

✅ Tout à fait d'accord.

Exactement en tant qu'architecte logiciel (ou Tech Lead, ou quiconque est en charge de l'architecture), il doit impliquer chaque membre de l'équipe dans les choix architecturaux - bien qu'il ait le dernier mot et finalement la responsabilité à leur égard -, également la décision Le processus de création qui mène à la création d'une application ou d'une partie de celle-ci doit impliquer tous les membres de l'équipe, y compris les développeurs front-end. Ceux qui font cela depuis assez longtemps peuvent être en mesure de trouver des lacunes dans l'expérience utilisateur ou la conception que d'autres ne verraient pas, et les impliquer dans le processus de prise de décision peut conduire à une meilleure expérience utilisateur et à un produit réussi.

Les outils frontend se commercialisent comme si le frontend était quelque chose que personne ne voulait faire et que personne ne devrait s'en soucier plus que nécessaire.

❌ Vous pouvez clairement voir la frustration augmenter à mesure que le message se développe, mais dans ce cas, je ne peux qu'être en désaccord.

Le marketing — tel que Josh le définit — des outils frontend n'a jamais banalisé ni tenté de simplifier les défis des développeurs, à l'exception de quelques rares exceptions. Ces outils visent de plus en plus à rendre le travail du développeur frontend plus simple et plus efficace, mais jamais banal, et il est vrai que la direction reste la même. La promesse n'est jamais de faire du développeur frontend un singe de code, mais de lui permettre de se concentrer sur ce qui est vraiment important : la création d'une expérience utilisateur réussie et l'impact sur le business et le monde qui l'entoure. Il en va de même pour le monde backend, où les outils ont évolué pour permettre aux développeurs de se concentrer sur le produit, plutôt que sur les choix techniques ou les problèmes de configuration.

Rappelons enfin que le monde des Relations Développeurs s'est développé de manière structurée ces dernières années, et que les éventuels faux pas de certaines entreprises ne doivent pas être considérés comme la norme.

Il semble que plus personne ne considère le frontend comme un élément essentiel du produit ; ils n'y voient que la jolie boîte dans laquelle le produit arrive.

❌ Ici aussi, hélas, je ne suis pas d'accord avec Josh.

Le frontend est un élément fondamental d'un produit, et son importance ne peut être sous-estimée, mais cela ne signifie pas qu'il faut nécessairement se livrer à la complexité et à l'abstraction. Le développement front-end est déjà suffisamment complexe pour ne pas nécessiter une conception ultra-sophistiquée ou des architectures abstruses, et exactement comme dans le monde back-end, la standardisation, si elle est effectuée en toute connaissance de cause, permet de ne pas ajouter de charge cognitive inutile et de se concentrer sur d'autres aspects. du produit.