Lors de la troisième journée de JCrete 2013, Martin Thompson nous a proposé une discussion autour de l’utilisation des frameworks sur la plateforme Java.
Les sessions ont toutes été enregistrées (audio seulement) et seront publiées sur le site WikiEducator à l’adresse : http://wikieducator.org/index.php?title=JCrete2013:Blog.
L’observation de départ est qu’il y a un très grand nombre de frameworks sur la plateforme Java. Ces frameworks sont censés nous simplifier la vie, pas nous rendre les choses plus complexes. Est-ce que ce contrat est rempli aujourd’hui ?
La discussion commence par une définition. Un framework :
- A une structure importante,
- Impose d’adhérer à une certaine philosophie,
- Impose des patterns de programmation.
Premier framework en ligne de mire : Spring. Martin nous fait part de son inquiétude lorsqu’il voit des développeurs préférer écrire une grande quantité de XML pour faire de l’injection de dépendances, plutôt qu’une simple classe composite.
De manière générale, on peut visualiser le coût d’entretien d’une fonctionnalité par le nombre de lignes de code qu’elle implique (frameworks inclus). Lorsqu’un projet de 2 pages Web démarre avec Spring et Hibernate, ce coût est exhorbitant (et probablement inutile).
Jesper Ubdy nous indique qu’au fil des années, il a tendance à vouloir utiliser le moins de frameworks possibles. Il est d’ailleurs rare que l’on retire des frameworks d’un projet, ce qui est inquiétant.
En fin de compte, il faut savoir ce que nos frameworks font pour pouvoir prendre les bonnes décisions. Par exemple, le problème des N+1 requêtes vient uniquement d’une mauvaise compréhension d’un ORM, il n’est pas dû à une mauvaise implémentation dans Hibernate. De même, une sur-utilisation de Spring n’est pas due au framework lui-même mais aux développeurs qui ne voient plus que à travers la librairie.
Yakov Fain nous explique que la plupart des développeurs qu’il voit en entretien pensent toujours aux frameworks qu’ils utiliseront pour résoudre un problème plutôt que d’opter pour la solution la plus simple ("Do the simplest thing that could possibly work" – Kent Beck).
Mattias Karlsson présente ensuite un intéressant parallèle avec le concept de Test-Driven-Development : le Framework-Driven-Resume (CV piloté par les frameworks). Les CV ressemblent de plus en plus à des listings de frameworks, or nos expériences devraient être d’abord des réalisations de use-cases business. Les développeurs ajoutent des frameworks aux projets pour que leur CV ait meilleur look.
Martin Thompson confirme en indiquant que des développeurs ont voulu essayer le Disruptor et ont donc fini par tordre un use-case pour pouvoir l’implémenter avec ce framework. Certains choix de technologie sont fait sur la base du hype, comme le classique "Je vais utiliser xxx technologie parce que Twitter l’utilise et que Twitter est cool".
Nous sommes dans une situation étrange où :
- Les développeurs sont payés pour implémenter des fonctionnalités,
- Les clients attendent des développeurs un TTM très bas, une haute productivité,
- Beaucoup de développeurs font des choix technique par rapport à leur carrière et non par rapport aux use-cases de leur société actuelle.
Cette discussion s’est terminée sur une question ouverte : Qu’est-ce qu’un bon développeur ?
- Est-ce un développeur qui a utilisé le framework x pendant 8 ans ?
- Est-ce un développeur qui a mis en production des application qui donnent satisfaction aux utilisateurs ?
- Est-ce un développeur qui a un diplôme d’une école réputée ?
- Est-ce un développeur qui a un grand portfolio de contributions à des applications open-source ?
- … ?