author
La keynote de fermeture de cette première journée de conférence à la QCon de Londres est présentée par Greg Young, co-fondateur et CTO d’IMIS, cabinet d’analyse de marchés boursiers à Vancouver BC. Greg Young est ce qu’on peut appeler un agitateur doublé d’un showman. Le moins qu’on puisse dire c’est qu’il sait réveiller une assemblée un peu fatiguée après plus de 8 heures de sessions cloud, mobilité, hardcore java, et j’en passe.
Greg Young met d’entrée de jeu les pieds dans le plat en expliquant que les développeurs aiment résoudre des problèmes que personne n’a. Il met pour cela en avant le concept de réutilisation, qui est trop souvent avancé à tord et à travers pour justifier le développement d’architectures ou d’applications bien trop complexes pour avoir une chance d’être réutilisées par une autre application du SI. Ce problème vient du fait que, le plus souvent, les développeurs aiment construire de l’abstraction autour de concepts simples. Nous voulons abstraire tout ce qui nous passe sous la main mais en tirons rarement bénéfice.
Il vaut mieux parfois réécrire le même code 2 ou 3 fois, plutôt qu’apporter du couplage dans le logiciel : abstraire les idées apporte de la complexité.
Pour argumenter le concept, il part d’un exemple qu’on rencontre souvent sur des projets informatiques qui démarrent. Lorsqu’on forme une équipe de développement pour un nouveau projet, l’équipe aura tendance à choisir les technologies avant même de connaître réellement le besoin (Tomcat, Spring, Hibernate et MySQL à tout hasard?). Oui, mais seulement en a-t-on vraiment besoin et est-ce seulement adapté à la problématique ?
Greg Young va plus loin en expliquant qu’il vaut mieux parfois “A piece of crap” réalisée en 2 semaines, plutôt qu’une vraie application bien codée réalisée en plusieurs mois (oui, c’est un brin provocateur). Une application réalisée rapidement amènera plus rapidement un feedback et suffira parfois à répondre au besoin.
La question n’est donc pas de savoir si l’application répond à l’état de l’art, mais surtout si elle répond aux besoins réels du client. Inutile de dire que les ORM, qui représentent l’abstraction et la surcomplexité par excellence, en ont pris pour leur grade. Si vous en doutez, posez vous la question de savoir sur quoi repose JPA :
- JPA est un socle commun à différentes implémentations d’ORM
- Les ORM sont eux-même des abstractions de la base de données
- Les bases de données reposent elles-même sur un langage normalisé depuis les années 90, le SQL.
Faut-il en déduire que nous avons un tout petit rien de complexité inutile ? Oui ! Avez-vous déjà travaillé sur des projets pour lequels vous avez déjà eu à changer de base de données ? Si oui, combien de temps aurait coûté une adaptation du code quand bien même il y aurait des changements de requêtage SQL à faire ? En conclusion: oui, nous employons inutilement trop d’abstractions de concepts.
Et pour ôter tout doute de l’esprit, Greg Young prend un exemple frappant, mais ô combien révélateur : si on vous demandait de réaliser un blog, l’idée de proposer une stack de développement à base de Java, Spring, Hibernate vous viendrait-elle à l’esprit, alors que des solutions bien plus adaptées existent ? De mémoire, il existe bien des projets de blogs implémentés avec ces technologies, mais n’est-ce pas sortir un bazooka pour tuer une mouche ?
La keynote de Greg Young, volontairement provocatrice, a pour objectif premier de nous rappeler d’être pragmatique dans notre approche du développement et de garder une vision simple des choses. Nous devons toujours prendre du recul sur les différents choix qui s’offrent à nous. C’est notre travail d’artisan de l’informatique d’adapter nos outils aux besoins du client.
Une de mes phrases préférées de la keynote est la suivante : “Developers love to solve problems that nobody have”. Autant dire que lorsque la salle a été sondée à main levée, on pouvait voir qu’une très grande majorité se reconnaissait dans cette description! Oui, nous, développeurs, avons tendance à trouver des problèmes là où il n’y en a pas. A nous de rester pragmatique et simple pour éviter de tomber dans ce piège classique, et ainsi “éviter de coder un CMS pour gérer une flotte de camions à ordures”, dixit Greg Young.