You’re full-stack enough

Ces derniers temps, on a tendance à dire que les développeurs d’applications par pile complète n’existent pas ou qu’il est impossible d’envisager la pile complète, alors que la pile technologique de la plupart des sites web a pris des proportions extravagantes.

Un rapide coup d’œil aux Moteur de recherche préféré nombreux articles que vous avez retournés en témoigne. Vous savez ce qu’on dit aussi : si c’est sur Internet, ça doit être vrai!

Est-ce difficile?

Être un développeur web au XXIe siècle

Empruntons la machine à voyager dans le temps pour revenir une vingtaine d’années en arrière. Les choses étaient bien plus simples! Les cadres côté client n’existaient pas à cette époque. Javascript ne servait qu’à intercepter un clic ici et là, à ajouter une poussière d’étoiles au curseur de la souris et à faire afficher des fenêtres superposables (non modales -fenêtres de navigateur qui apparaissaient partout sur l’écran).

Personne ne prenait Javascript au sérieux. C’était une option, un ajout après coup. Tout l’aspect logique était codé, côté serveur, au moyen de différents langages. HTML et CSS étaient mis ensemble sur le serveur et envoyés directement au navigateur. Perl et PHP se retrouvaient partout. Ruby on Rails et les autres cadres MVC ne sont devenus populaires qu’aux environs de 2006. Même s’ils ont effectivement tout changé, leur rendu est surtout demeuré du côté serveur.

En d’autres mots, la plupart des développeurs d’applications travaillaient par pile complète à cette époque, à divers degrés. Bien sûr, certaines personnes étaient plus habiles avec les bases de données et la logique métier, tandis que d’autres se consacraient à la logique de présentation.

La principale différence résidait dans un certain manque de distinction entre les données et la présentation. Toutefois, l’industrie a fini par adopter des techniques d’amélioration progressives : HTML pour la structure, CSS pour le formatage et Javascript pour le comportement. Dans ce cas, il était convenu qu’il pouvait être désactivé par l’utilisateur sans nuire à l’emploi des principales fonctions. Cela demeure un objectif louable et un aspect que l’industrie devrait reconsidérer, mais je m’éloigne du sujet.

Années 2010 : décennie du gâteau étagé

Google Chrome a été lancé à la fin de cette période,
alors que le moteur Javascript, beaucoup plus rapide, permettait tout ce qui nous est familier maintenant. Sans le V8 nous nous retrouverions probablement dans un monde très différent (peut-être avec un meilleur langage
côté client, qui sait?) En résumé, tout a commencé avec le code pirate jQuery qui communiquait avec les interfaces de programmation d’applications (API) plus ou moins uniformes pour aboutir au fouillis React/Babel/Webpack dans lequel nous nous trouvons aujourd’hui.

La principale différence, c’est qu’au lieu de laisser le serveur rendre les données directement en HTML/CSS, nous disposons dorénavant d’API pour données uniquement et d’importantes applications côté client qui effectuent 99 % du rendu. Des raisons historiques expliquent ce phénomène, mais il relève surtout de l’arrivée du iPhone en 2007 et d’Android en 2008. Les navigateurs des services mobiles n’étaient pas très rapides, alors la plupart des entreprises ont commencé à produire des applications d’origine avec des API XML ou JSON pour les seconder. Nous parlons ici de véritables applications d’origine, pas de fausses comme avec React!

Il serait facile de se dire « Nous avons déjà une API, pourquoi se donner autant de mal? » Voilà exactement où nous en sommes en fait. 

La plupart des gens qui prétendent que la pile complète
n’existe pas fondent d’ailleurs leur argumentation là-dessus. Les développeurs d’applications d’arrière-plan ont besoin de savoir comment traiter les bases de données, comment concevoir les API, comment assurer la sécurité, le rendement et ainsi de suite. Et nous n’avons pas encore parlé de la configuration du serveur, de l’automatisation et de tout ce que nous rangeons encore commodément dans le domaine du développement et de l’exploitation.

Pour arriver à tout faire tenir ensemble, les développeurs côté client se doivent de connaître au moins un cadre, de pouvoir se débrouiller avec des outils de construction ridiculement compliqués, de composer avec des problèmes de compatibilité de navigateur et de posséder des notions de base d’interface ou d’expérience utilisateur.

Si nous considérons les choses sous cet angle, c’est assez vrai! J’ai travaillé comme développeur web pendant plus de 20 ans (eh oui, 20 ans!) et je peux pratiquement le faire. Cependant, vous devez toujours passer plus ou moins de temps des deux côtés de la frontière HTTP plutôt que de tout réaliser d’un seul coup.

Mais ce n’est pas tout, en fait, nous sommes encore loin du compte!

Vous n’avez pas à tout savoir.

En réalité, il en faut très peu pour démarrer. Tout dépend
de la portion de pile que vous souhaitez contrôler et personnaliser.

Il est tout à fait possible de créer une application
entièrement fonctionnelle même si vous ne connaissez que le côté client.
Il existe de nombreuses solutions à constance des données basées sur des API,
gratuites ou très abordables et ne nécessitant aucune configuration.

La plateforme Firebase de Google en est un excellent exemple. Elle peut même héberger votre code côté client et fournir la fonctionnalité en temps réel
(avez-vous déjà eu envie de bâtir votre propre clone de Slack?). Parse offre également des fonctions
semblables avec code complètement ouvert si vous prévoyez l’héberger vous-même. Les images Docker préconçues sont assez faciles à trouver et permettent une configuration pratiquement instantanée.

Il y a aussi Glitch. Il propose un éditeur web qui vous
permet de déployer votre application en appuyant sur un bouton. Vous n’avez même pas à vous préoccuper de configurer un environnement de développement local! À ce stade, c’est presque aussi simple que « on le configure et on n’y pense plus! »

Saviez-vous qu’en plus Glitch réduit encore les barrières
d’entrée pour permettre aux développeurs d’applications d’arrière-plan de construire leur application? Inutile de se débattre avec Babel et Webpack pour faire fonctionner une configuration React! Formidable, n’est-ce pas? Vous
pouvez paresseusement réaliser votre pile en tirant parti de fonctions infonuagiques sur AWS Lambda ou Google Cloud pour créer des API pratiquement sans code et vous voilà fin prêt.

Trop long; non lu : Tout est une question de contrôle d’accès

A-t-on raison de dire que les développeurs qui utilisent
ces outils procèdent par « pile complète »? Oui, absolument! Après tout, ils créent des applications entièrement fonctionnelles. Tout le reste est hors sujet.

Évidemment, les gens se spécialiseront davantage dans un domaine ou un autre, mais il est très possible d’acquérir une connaissance suffisante de toute la pile. Comme résultat final, on obtiendra des applications complètes fonctionnant aussi bien que des codes rédigés conçus à partir de rien de la façon la plus puriste. 

(À ce propos : Dans cette situation, vous ne rédigeriez pas 100 % du code non plus. Il suffit de jeter un coup d’œil à ce remarquable dossier nœud_modules pour prendre une leçon d’humilité.)

À TELUS Digital, nous ne nous attendons pas à ce que nos développeurs partent de rien. Nous disposons d’un ensemble complet de trousses de démarrage pour les
applications isomorphes, les API et ainsi de suite. Ces trousses fournissent la configuration automatique des outils de construction, des essais automatisés, des outils de processus CI/CD ainsi qu’à peu près tout ce dont les développeurs ont besoin pour se mettre à l’œuvre, sans parler des lignes directrices, des meilleures pratiques et des modes de codification.

À tous les niveaux, les développeurs emploient ces outils.
Il est entendu que les développeurs d’arrière-plan et côté client agiront librement en ce qui a trait au code, collaboreront et passeront de l’autre côté au besoin. Je ne sais pas combien de fois j’ai entendu dire : « J’aimerais
pouvoir développer les applications par pile complète, pouvons-nous faire équipe pour ce projet? » Finalement, tout est une question d’attitude.

Le travail de développeur est difficile, alors on s’attend à une constante remise en question de notre expertise. Le syndrome de l’imposteur est très répandu dans l’industrie et de nombreux lieux de travail peuvent se révéler plus stressants qu’il ne le faut.

Cela ne donne cependant pas le droit aux développeurs de
se tenir sur la défensive à cause de leurs propres insécurités. Il n’y a pas de honte à employer les outils dont on dispose pour se faciliter la vie! Vous ne voyez pas les ébénistes se critiquer les uns les autres pour avoir utilisé des outils électriques qui servent à couper, à sabler et à tourner des pièces de bois, ni les mécaniciens prétendre qu’un collègue n’est pas un véritable professionnel parce qu’il se sert d’un pont élévateur hydraulique, d’un percuteur et d’un compresseur.

C’est donc vrai, les développeurs d’applications par pile complète existent. Il y en a beaucoup et vous en faites probablement partie. Soyons donc bons les uns envers les autres et nous réaliserons de grandes choses!

Suivez-nous sur Instagram et Twitter (@telusdigital) pour participer à d’autres événements et obtenir des nouvelles. Vous souhaitez vous joindre à l’équipe? Consultez le site Carrières.