Forts de notre expérience dans l’IT, d’une dizaine d’années passées à accompagner nos clients et recruter des talents, nous souhaitons vous partager ici nos observations et retours d’expériences sur l’évolution du marché Java, les fortes adhérences qui se poursuivent avec la communauté Spring, ainsi que les mutations qui s’opèrent dans le rôle de développeur.
.png)
Article co-écrit avec Nourdine Bouaghaz et publié dans l'édition 100% Java du Magazine Programmez de l'été 2021.
Forts de notre expérience dans l’IT, d’une dizaine d’années passées à accompagner nos clients et recruter des talents, nous souhaitons vous partager ici nos observations et retours d’expériences sur l’évolution du marché Java, les fortes adhérences qui se poursuivent avec la communauté Spring, ainsi que les mutations qui s’opèrent dans le rôle de développeur.
Nous aborderons les évolutions de compétences et de posture nécessaires à nos yeux pour répondre aux enjeux d’architectures modernes de plus en plus complexes (microservices, services managés, décentralisation, performance, déploiement, etc.).
Nous partagerons également un regard critique sur l’utilisation des frameworks qui peuvent éloigner les développeurs des concepts fondamentaux.
Enfin, nous tenterons d’apporter une réponse concrète aux compétences sur lesquelles nous préconisons d’investir pour affronter sereinement les défis techniques.
Développé par Sun Microsystems depuis 1995, Java devient un produit d’Oracle suite au rachat de Sun par ce dernier en 2009, jusqu’à se hisser au premier rang des langages orientés objet (quelques chiffres sur https://www.java.com/fr/about/).
La sortie régulière de versions majeures avec chacune son lot de features structurantes consolide son adoption par le marché, notamment dans le cadre de grands projets.
De plus, challengé par de nouveaux langages dans le core de la JVM (Clojure, Scala et Kotlin principalement) et intégré comme premier langage sous Spring, Java ne cesse de s’adapter et évoluer.
Le succès de Spring MVC en 2008 puis de Spring Boot l’a aidé à se maintenir au rang des langages préférés.
Pour en savoir plus :
L’idée n’est pas de développer une liste exhaustive de pour et contre mais de balayer rapidement les principales caractéristiques qui confortent notre idée qu’il semble adapté aux projets de grands groupes.
Seules les versions 11 (sortie en septembre 2018) et 17 (prévue pour septembre 2021) feront l'objet d'une LTS. (https://www.oracle.com/java/technologies/java-se-support-roadmap.html)
Depuis sa sortie en mars 2014, la version 8 a apporté d’importantes fonctionnalités dans la mise en place d’architectures modernes et “Cloud Ready”.
L’apparition des streams, des lambdas, la refonte de l’API de la gestion des dates, les implémentations d’interface, etc. améliorent grandement le quotidien des développeurs.
Aujourd’hui encore, nous constatons que la majorité des projets de nos clients restent figés sur la version 8 du JDK.
Cependant, ceci pose la question de la maintenance et surtout de la fin du support officiel de cette version.
L’étude publiée par JetBrains (https://www.jetbrains.com/lp/devecosystem-2020/java/) conforte notre vision avec une version 8 qui reste la plus répandue. D’autres études, comme celle publiée par Snyk (https://snyk.io/blog/jvm-ecosystem-report-2020), précisent également que le JDK 8 reste la plus utilisée en production.
Spring MVC et plus récemment Spring Boot ont grandement contribué à la démocratisation de Java.
Les applications REST basées sur Spring MVC prenant en charge le format JSON dans Tomcat demandaient la mise en place d’une dizaine de dépendances avant de compléter la configuration.
Le choix de Spring Boot s’est donc imposé en facilitant le quotidien des développeurs en supprimant certaines de ces difficultés grâce à :
Spring Boot coïncide également avec le lancement à grande échelle de projets de démantèlement de monolithes. Le duo Java 8 / Spring Boot devient le choix plébiscité pour initier ces changements de paradigmes d’architecture avec la promesse d’obtenir des systèmes plus ouverts (facilitant l’accès par des APIs), modulaires et évolutifs.
Avec Spring Cloud, Spring contribue à la démocratisation du microservice grâce à la gestion de la configuration, la découverte de services, passerelles de service, au pattern circuit breaker, fallback, etc.
Nous constatons aussi que ces facilitations s’accompagnent, à notre sens, de compétences Ops qui deviennent de plus en plus importantes dans le quotidien d’un développeur pour minimiser les problèmes de déploiements, notamment en production.
D’ailleurs, il est judicieux de se demander à quoi bon disposer d’une profusion de microservices si la gestion de la séparation des responsabilités, des déploiements, de l’interconnexion de services, etc., est douloureuse ?
Spring MVC, Spring Boot, Spring Cloud, etc. sont des frameworks qui apportent une réelle valeur indéniable.
Cependant, la couche d’abstraction apportée peut éloigner nos développeurs des concepts fondamentaux et les amener à appliquer le “FDD”*, sans prise de recul, se contentant ainsi de laisser faire la “magie” de Spring.
C’est pourquoi nous préconisons d’investir judicieusement son temps d’apprentissage et de pratique dans des concepts fondamentaux agnostiques aux langages, aux frameworks ou aux librairies : injection de dépendances, inversion de contrôle, immutabilité, effets de bord, idempotence, etc.
Ces concepts fondamentaux restent un investissement sûr, transposable et durable quelles que soient les évolutions de frameworks à venir.
*FDD, Frameworks Driven Development, concept humoristique que nous utilisons chez CodeWorks pour décrire le comportement d’un développeur ou d’une équipe qui sait utiliser, voire devient spécialiste d’un framework, mais n’a pas ou peu de connaissances ni prise de recul dans la conception système ou l’architecture logicielle sans ledit framework.
Les technologies évoluent très vite et cette fuite en avant est déjà perdue d’avance pour quiconque souhaiterait suivre cette cadence infernale.
La technologie évoluera toujours plus vite que votre capacité d’apprentissage.
Il est alors plus judicieux de prendre un peu de recul, capitaliser et investir votre temps sur des compétences “transférables”.
Ces compétences vous permettront d’appréhender plus facilement les évolutions technologiques à venir en vous appuyant sur des connaissances qui perdurent depuis plusieurs dizaines d’années maintenant.
Pour cela, concentrez-vous sur l’apprentissage et la mise en pratique des principes fondamentaux.
Un mentor ou une communauté de pratique, voire une participation au développement d'un projet open source peuvent également vous être d’une grande aide.
Le contexte Covid a aussi favorisé la mise en place d’évènements en visioconférence en France, en Europe, voire dans le monde entier.
Voici quelques conseils que nous pouvons vous apporter pour accompagner votre parcours de développement de compétences :
Et si vous avez fait le chemin inverse, rien n’est perdu pour commencer à appliquer ces conseils dès maintenant.
De même, voici quelques conseils sur l’apprentissage des technologies :
Les offres de poste de développeurs s’apparentent de plus en plus aux compétences recherchées pour assurer le fonctionnement optimal d’un service IT complet.
L’écosystème Java confirme cette vision puisqu’il imbrique, à lui seul, une quantité parfois déconcertante de technologies.
Cela conforte, notre idée, qu’une évolution des logiciels de pensée est nécessaire.
Qu’il soit écrit en Java ou dans un autre langage, un code compréhensible par la machine est facile à écrire, mais un code lisible et facilement compréhensible par d’autres développeurs l’est beaucoup moins.
La base de code se doit d’être facilement compréhensible par d’autres afin qu’elle ne se transforme pas en dette technique comportant des bugs douloureux à corriger, de la complexité non justifiée qui aboutirait à un sentiment d’incertitude et un manque de confiance.
C’est la connaissance et la mise en pratique des principes d’architecture, de design, des méthodologies de tests, de découverte et l’appétence pour les connaissances métier qui permettent l’élaboration d’un code lisible et compréhensible.
Au sein de nombreux projets informatiques, les rapports de force entre acteurs métier et équipes de développement existent, parfois au détriment de la qualité du produit final.
Ils ne permettent pas d’instaurer un climat serein et apaisé nécéssaire à la production d’un code de qualité, fiable, qui répondra aux exigences et aux enjeux business partagés par toute l’équipe.
En effet, il est parfois difficile de faire comprendre aux parties prenantes métier d’un projet IT que la satisfaction du client et la qualité du produit final dépendent en grande partie des pratiques mises en œuvre pour concevoir ce code.
Il est donc de notre devoir d’accompagner ces évolutions de culture technique et méthodologique.
Nous sommes également convaincus que le développeur doit s’inscrire dans un dépassement de fonction. Savoir s’extirper de la posture de “doer” pour accompagner, comme pourrait le faire un coach, la mise en œuvre de bonnes pratiques pour concevoir un code :
Dans le prolongement de la culture DevOps qui consiste à rapprocher les équipes de développement et systèmes, les compétences Ops deviennent de plus en plus précieuses pour développer une vision plus responsable : “You build it, You run it”.
La montée en puissance d’applications “Cloud Ready” et l’émergence de nouveaux paradigmes, type Serverless, promus par les Big 3 que sont AWS, Azure et GCP, ne font que confirmer cette tendance.
Scrum, par exemple, repose sur trois piliers : transparence, inspection et adaptation.
La promesse de l’agilité consiste à offrir de la visibilité sur le travail d’une équipe développement pour :
Malgré toutes ces belles perspectives, certains projets s’inscrivent aujourd’hui dans une approche “Scrum Zombie”. À ce titre, Christiaan Verwijs, Johannes Schartau et Barry Overeem apportent des retours d’expérience intéressants : https://medium.com/the-liberators/zombie-scrum/home
Le “Scrum Zombie” est quelque chose qui ressemble à Scrum et où l’on peut voir implémenter les rôles, les événements artefacts du framework, mais sans aucune collaboration entre les parties prenantes et où personne ne semble se soucier d’améliorer quoi que ce soit.
Il se produit souvent dans des organisations qui se concentrent sur l’optimisation d’autre chose que l’agilité réelle et ont rarement une réponse claire sur ce qui fait la valeur de leur produit.
Comme les zombies titubant sans savoir où ils vont, ces équipes travaillent très dur, mais sans arriver à un résultat précis ou efficace.
Les équipes se cachent alors derrière la complexité du produit, les limites technologiques ou le manque de connaissances métier.
Enfin, dans ce type de contexte, les organisations ne créent pas d’espace protégé pour assumer sereinement les échecs.
A contrario, les équipes s’attachent à développer des stratégies défensives pour éviter cette incertitude.
Tout développeur doit être conscient qu’il n’écrit pas du code que pour lui, mais un code universel, simple, performant, accessible et compréhensible par tous.
Pour cela, il doit être en capacité d’éliminer toute complexité inutile.
Pour ce faire, nous recommandons quelques ouvrages qui peuvent accompagner votre cheminement vers ce noble objectif et vous permettre d’investir judicieusement votre temps d’apprentissage :
Attention, nous attirons votre attention sur le fait que ces ouvrages vous permettront d’explorer de nouveaux horizons ou d’approfondir vos connaissances déjà acquises mais nous vous recommandons vivement de pratiquer par du code, du code et encore du code !
Nous constatons depuis plusieurs années un attrait grandissant des équipes projets tant pour les compétences comportementales que techniques.
Nous ne pouvons que nous en réjouir, car nous sommes convaincus que le prisme technique seul ne peut suffire pour contribuer efficacement, comprendre les enjeux métier et interagir convenablement au sein d’un projet.
Cela en dit beaucoup sur votre honnêteté intellectuelle et facilitera l’apprentissage et l’évolution. Nous le valorisons comme un terreau fertile pour accepter le lâcher-prise notamment dans les phases d’accompagnement (mentoring, pair ou code review, par exemple) et la prise de conscience de ses propres limites.
Sans elle, pas d’évolution possible. Assurez-vous donc de ne jamais en manquer ou faites en sorte de la stimuler sans arrêt pour maintenir un intérêt pour votre projet.
Toute complexité inutile a un coût important pour la viabilité d’un produit et c’est cette sensibilité qui permettra de produire une base de code fiable qui ne virera pas rapidement à la dette technique impossible à maintenir.
Le “mentor/mentoré.e” sait qu’il ne peut pas tout savoir. De ce fait, sur un sujet X ou Y tantôt il aura les connaissances qui permettront d’aider les autres, tantôt il bénéficiera et apprendra de celles des autres.
Depuis quelques d’années, nous constatons également une réelle évolution des critères qui motivent l’engagement des développeurs pour tel ou tel projet.
Les critères technologiques avaient une place importante qui encourageait les offres de poste type inventaire à la Prévert des technologies présentes sur les projets, même les plus mineures.
Ces critères ont évolué pour laisser plus de place à :
Notre Manifeste est le garant des droits et devoirs de chaque CodeWorker et des engagements que CodeWorks a vis-à-vis de chaque membre.
Il se veut réaliste, implémenté, partagé et inscrit dans une démarche d'amélioration continue.
Tu veux partager tes connaissances et ton temps avec des pairs empathiques, incarner une vision commune de l'excellence logicielle et participer activement à un modèle d'entreprise alternatif, rejoins-nous.
