CodeNews#3 -Écosystème Java : évolutions du marché, postures et enjeux à venir pour tout développeur

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.

Un rapide tour d’horizon

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 : 

• https://blog.jetbrains.com/idea/2020/09/a-picture-of-java-in-2020/
• https://www.jetbrains.com/lp/devecosystem-2020/java/
  

Un langage qui convient plutôt aux projets importants, pourquoi ?

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.

• Démocratisation : le langage dispose du support d’une communauté très importante et particulièrement active de plus de 9 millions de développeurs qui participent à sa forte adoption dans le monde entier (1) ainsi qu’à un nombre important de ressources (documentation, tutoriels, vidéos, etc.) qui rendent son apprentissage plus accessible.

• Maturité : Des millions, voire milliards d’applications pour différents secteurs et entreprises ont permis de tirer des enseignements, consolider les connaissances, résoudre les problèmes et documenter largement.

• Rétrocompatibilité ascendante : il offre la possibilité d’exécuter du code conçu il y a plusieurs années sur une version plus récente du JDK. Ce point rassure les organisations qui sont assurées que le code, modulo certains ajustements, fonctionnera encore pour les années à venir.

• POO (2) : Ce paradigme offre différents principes (encapsulation, polymorphisme, héritage, etc.) qui assurent une expression du métier plus aisée et des facilités dans sa conception. L’arrivée, depuis la version 8, du paradigme fonctionnel ouvre également de nouveaux horizons. 

• Indépendance : Il s'exécute sur n'importe quelle plateforme et n'a besoin que d’une Java Virtual Machine qui s’adapte à tout type de système d’exploitation et assure une portabilité du Java Byte Code.

• Langage de haut-niveau : à la différence de C ou C++, les problématiques d’allocation de la mémoire et des erreurs inévitables sont totalement prises en charge par le système. Le développeur peut alors se concentrer sur l’expression du métier
• Multithreading : il dispose de la capacité à exécuter plusieurs threads (tâches) en même temps et en parallèle.
• Distribution : à l'ère des services managés (cloud computing), il fournit les fonctionnalités nécessaires pour relier des ressources distantes et optimiser les performances des applications développées.
  

Quelques limitations connues qui peuvent freiner son adoption

• Performances : il reste gourmand en mémoire et plus lent que les langages compilés nativement tels que C ou C ++. C’est d’ailleurs une de ses limites lorsque des contraintes de temps réel se présentent, même si des alternatives, type GraalVM, voient aujourd’hui le jour.
• Gestion de la mémoire : elle est facilitée via le garbage collection qui affecte fortement les performances de l'application puisque tous les autres threads doivent être arrêtés pour permettre au thread “ramasse-miettes” de fonctionner.
• Bouleversement du modèle économique : Une nouvelle cadence de version est mise en place depuis 2018, où de nouvelles « versions » de Java sont disponibles tous les 6 mois. Cependant, cette nouvelle cadence n'inclut pas systématiquement le support à long terme.
  

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)

Un fort ancrage sur le JDK8

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.

De fortes adhérences avec la communauté Spring

Spring Boot toujours autant plébiscité par la communauté Java

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 à :

• Starters
• L’auto-configuration
• BOM (Bill Of Materials) de dépendances
• Applications “Production-Ready” via Actuator
  

Spring Boot, bonjour les architectures microservices !

Une accélération du démantèlement des monolithes

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.

L’avènement de Spring Cloud et la facilitation des déploiements “Cloud Ready”

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 ?

Les frameworks, des abstractions nécessaires pas toujours bénéfiques

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.

Pourquoi vous ne devez pas investir TOUT votre temps dans l’apprentissage des frameworks ?

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 :

• Lancez-vous dans l’apprentissage des bonnes pratiques de design de code avant de vous lancer dans un langage
• Lancez-vous dans l’apprentissage des architectures évolutives avant de vous lancer dans l’apprentissage des microservices, par exemple
• Lancez-vous dans l’apprentissage des concepts de livraison continue avant de vous intéresser à une technologie de conteneurisation, type Docker, par exemple
• Lancez-vous dans l’apprentissage du fonctionnement du Web, HTTP et REST avant de vous intéresser à un framework ou bibliothèque Front, type Angular, React ou Vue, par exemple

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 :

• Identifiez une technologie qui peut vous apporter de nouvelles compétences ou un regard critique et remettre en question vos compétences déjà acquises
• Le temps est votre meilleur conseiller, apprenez à être patients avec vous-même
• Les frameworks, bibliothèques et outils vont et viennent, les principes et concepts fondamentaux restent
• Modulez votre investissement entre 70% sur les fondamentaux et 30% sur des frameworks, bibliothèques et outils.
  

Comment contribuer à des évolutions de culture technique ?

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.

Commencer par écrire un code simple et compréhensible par tout le monde

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. 

Définir un haut niveau d’exigence qualité

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.

S’inscrire dans un dépassement de fonction

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 :

• Facile à lire
• Facile à comprendre
• Facile à tester
• Facile à débugger
  

Développer une culture de la responsabilité et de l’opérabilité

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.

S’adapter à l’évolution de culture et pratiques agiles

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 :

• éviter les effets tunnels
• permettre des retours itératifs et constructifs
• définir des mises en production plus régulières
• fluidifier les interactions
  

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.

Accueillir et assumer une posture d’apprenant

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 :

• The Pragmatic Programmer | Auteurs : David Thomas and Andrew Hunt
• Clean Code | Auteur : Robert C. Martin
• Domain-Driven Design | Auteur : Eric Evans
• Continuous Delivery | Auteur : Jez Humble
• The Software Craftsman | Auteur : Sandro Mancuso
• Soft Skills : The Software Developer’s Life Manual | Auteur : John Sonmez
  

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 !

De l’importance des compétences comportementales 

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.

Savoir dire “je ne sais pas” 

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.

Faire preuve de curiosité

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. 

Du pragmatisme pour combattre l’over-engineering

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 apprenant

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.

Des choix de carrière qui évoluent : la portée du produit prend peu à peu le pas sur l’intérêt pour les technologies

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 à :

• des projets qui ont un impact positif sur l’utilisateur final
• un équilibre vie professionnelle / vie personnelle en disposant de temps libre, par exemple
• un développement de compétences financé et assumé par l’entreprise 
• un collectif riche, divers et compétent pour poursuivre son évolution en qualité de “mentor/mentoré”