@Mickael_istria, sur le sujet des débutants :
Sitôt l'étudiant sorti de l'école, la première entreprise venue lui proposera un sujet JEE (qu'il soit EJB ou Spring) parce qu'il n'y en a pas d'autres. Ou alors très exceptionnellement.
Le jeune il arrive avec son Bac+2 Java, zéro année d'expérience, il devrait trouver un job. Or, à l'inverse de ce qui se passe pour les offres PHP où de nombreuses sont destinées aux débutants, c'est une inflation des années d'expérience réclamées que l'on observe dans celles Java, et cette expérience qui est demandée, elle est demandée sur le framework cible. Et c'est là qu'il y a une erreur.
Pourquoi ?
1) Le DSI a ouvert un poste parce que dans 80% des cas, la MOA ou la direction lui a demandé de faire évoluer ou de créer de nouveaux traitements métiers.
Ce sont des services de l'entreprise qui ont besoin de :
- nouvelles pages web de saisie de configurations d'articles vendus,
- nouveaux batchs de traitement de commandes,
- contrôles d'ordre de fabrication,
- états analytiques comptables spécifiques.
- etc.
et le DSI ne peut de toutes façons que s'exprimer en termes métiers vers sa direction qui ne comprendrait pas d'autres discussions que celles sur l'avancée des développements dans les processus métiers de l'entreprise et les règles de gestions choisies ici ou là.
2) Le rôle d'un framework est de faciliter le développement. Pour simplifier, un bon framework devrait me permettre de me limiter à faire mes implémentations dans les couches objets métiers, service, web et coordination / contrôleur, sans rien me demander de plus.
Or que se passe t-il ? On demande à chaque développeur de savoir faire le développement métier (ce qui est normal), ainsi que d'avoir la très bonne compréhension du framework dans lequel il s'inscrit et savoir assurer sa configuration. Choses qui ne s'acquièrent (si on si intéresse) qu'après un bon nombre d'années.
Alors que ça n'a pas de nécessité.
Dans la mesure où avec le temps, les configurations se font en nombre de plus en plus limité (on en fait beaucoup au début, et puis après, elles y sont quasiment toutes), c'est à l'architecte JEE (ou au tech leader) de l'entreprise de s'en occuper et dans l'absolu je trouve légitime qu'il ait ces rôles :
- s'il y a une complexité dans le framework, mettre en place les classes d'entreprise parentes ou autres dispositifs qui permettront de passer l'obstacle le plus facilement possible.
- s'il y a un standard ou une bonne pratique à faire connaître et qu'il pense qu'il n'est pas acquis que tous la connaissent, il ne doit pas se formaliser de devoir l'expliquer, fût-ce souvent.
- il est le seul qui intervient dans les applicationContext.xml et standalone.xml. S'il s'aperçoit que ça lui est pénible de devoir intervenir trois fois par semaine sur l'applicationContext.xml au nom de l'un ou l'autre développeur, il sera le plus concerné pour trouver comment limiter ces désirs sans fin de configurations de Spring.
- il gère les évolutions de versions de composants JEE et API.
En un mot, l'architecte JEE doit rendre le framework invisible. C'est son job. Et à mon sens, il n'en a pas d'autres.
En exagérant et en poussant à la limite, je pourrais écrire mes méthodes de service dans un @Named, et ne pas savoir si c'est un @Service de Spring ou un @Stateless d'un serveur d'application que j'ai derrière ! Je n'ai pas besoin de le savoir.
Et c'est ainsi que l'on peut prendre des débutants connaissant seulement :
- un framework web : JSF, Angular, Struts, GWT...
- JPA 2 (même pas Hibernate : l'architecte JEE doit le dissimuler ; même pas les mappings entités <-> objets métiers : c'est aussi à l'architecte JEE de les dissimuler, à lui d'être un pro de Dozer et autres ; et même MongoDB c'est du JPA quand on s'y prend bien : là aussi l'architecte il doit faire que les développeurs arrivent doucement à MongoDB et non pas demander à ce qu'ils le connaissent déjà).
et c'est tout ! Et encore : moi, je n'ai besoin que d'un débutant connaissant le framework web : JPA avec le temps, je l'y forme. D'autant que normalement, si le taf il est bien fait : il y a des DAO depuis longtemps pour esquiver JPA, et je n'ai même pas besoin qu'ils le connaissent.
Les transactions, le débutant, il n'a pas besoin de connaître (on se démerde pour que tout passe en REQUIRED par défaut et on règle les adaptations exceptionnelles derrière son dos, s'il le faut). On lui expliquera les choses avec le temps.
Les objets métiers on peut lui apprendre comment les faire bien en live.
Les batchs on lui apprend le principe en ayant simplifié le mécanisme des batchs du framework pour les rendre utilisables avant.
Le débutant il doit se concentrer sur le métier. Sur rien d'autre. S'il s'occupe d'autre chose, c'est que l'architecte JEE / Tech leader il a mal fait son boulot.
On a besoin que d'un seul architecte pour assurer tout cela avec une bonne cohérence. Mais il faut qu'il le fasse. En entretien, il est fréquent que l'architecte JEE ait le toupet de poser des questions aux candidats pour savoir s'ils savent faire... ce qui est son job à lui ! Et je suis sidéré et assez exaspéré par cela.
Une entreprise où l'architecte JEE / tech-leader bosse bien est libre parce qu'elle peut avoir plein de développeurs de zéro à dix ans d'expérience (avec un bagage fait de : web + JPA seulement) qui agissent strictement sur des problèmes métiers de plus en plus complexes,
une entreprise où l'architecte JEE est un gargarisateur, il parle et critique, mais répartit le boulot parmi les développeurs et en fin de compte, ceux-là ne se concentrent plus sur leur tâches métiers mais s'interrompent quotidiennement sur des problématiques de configurations et d'architecture technique, et pour lesquels il faut une liste à rallonge de compétences et un minimum d'années d'expérience.
Donc, pour moi aujourd'hui, le problème en entreprise vient de l'architecte JEE. Une fonction qui est bien trop vite accordée à l'unique personne qui doit l'avoir, sans prendre le temps de vérifier si elle voudra bien libérer l'équipe de développement des contingences du serveur d'application choisi.
@tchize, sur le remplacement des composants standards de JBoss
C'est vrai ce que tu écris. Il faudrait se limiter à l'emploi des composants standards de JBoss.
Mais dans 100 à 150% des entreprises qui utilisent JBoss depuis plus cinq ans, tout redéfinit tout et l'on est souvent aux prises avec des jar hells à la façon des DLL hells de l'époque C++ de Windows.
Partager