Pourquoi les développeurs RAM-t-ils ?

Alors Mr.Doe, êtes-vous à l'aise avec Javascript ? Connaissez-vous NodeJs ? Êtes-vous plutôt React ou Angular ? Docker et Kubernetes n'a plus de secret pour vous ?

À l'évidence vous venez de recevoir un email de votre ESN préféré pour un poste sur-mesure. Heureusement que vous avez deux mains et que vous serez lui demander ce qu'est Javascript pardi !? Je suis développeur à tendance BackEnd.

Comment nous en sommes-t-on arrivé là ?

Il y a un temps, l'environnement d'un développeur se composait de 4 à 5 stacks techniques:

• 2 languages POO (PHP, Java, .Net...)
• 2 ou 3 languages bas niveaux (C, C++, C#, Shell...)
• Et pour les curieux un peu d'Apache2 ou Windows Server pour les téméraires.

Une grosse partie du boulot du développeur se basait sur ça capacité à résoudre des problèmes métiers par des solutions algorithmiques, désormais, c'est l'adaptation qui est le curseur de réussite. Utiliser des outils pré-faits avec une logique intégrée afin de simplifier la gestion de projet et tenir les délais de production.

Le nouveau framework à la mode

L'entreprise à fait le choix d'un framework pour tous ses projets.

Celui-ci on le connaît, il répond à tous les usages, il est idéal pour nos projets, il ne fait rien comme les autres, c'est le nouveau framework à la mode.

Il s'est imposé dans l'entreprise parce qu'on n'ose plus sortir son code legacy caché dans le placard par respect pour les anciens qui sont partis en Burn-Out. Quelques jours plus tard, pour des raisons de scalabilité hélas vous devrez retravailler tout un process, soit 7 000 lignes de code parce que la documentation disait de faire comme ça, mais ne prenait pas en compte les problématiques de flux important. C'est une chose qui arrive souvent et qui est liée à un souci lors de la composition de l'architecture de l'application, cela peut être évité par le développement de petits composants applicatifs/services, mais rarement justifié dans l'utilisation de framework. Bah oui, ce service existe déjà dans le framework alors pourquoi le redévelopper ?

Une jungle logisticielle

Par l'absence de réelle réflexion sur les besoins d'un projet, nous perdons en valeur rajoutée, nous uberisons notre métier. Pourquoi ce lancer sur de la R&D dans le domaine de la reconnaissance d'image lorsqu'on peut utiliser Google Vision ? Pourquoi travailler sur un moteur de recherche performant alors qu'on a ElasticSearch ? Nous faisions le choix d'une complexité logicielle exponentielle face à des métiers qui on fait leurs preuves sur le temps. Quite à créer des applications innovantes, n'ayons pas peur de mettre de l'intelligence local au cœur du service. Je n'ai rien contre l'intégration de nouvelles technologies dans nos projets, mais que cela soit fait de manière raisonnée en évitant l'early adoption.

Le développeur du turfu

Il est important de réfléchir à notre métier afin de s'engager dans une démarche sur le long terme, des standards à préconiser, des techno à favoriser. Sans quoi, nous risquons de perdre en cohérence dans nos équipes d'où la création de domaine comme le DevOPS. Est-il normal de devoir se doter d'interface humaine afin de parler de technique dans une équipe technique ?

Tous ces moments se perdront dans l'oubli, comme des larmes dans la pluie.