Published by

Il y a 9 ans -

Temps de lecture 4 minutes

QCon London – Developers Have a Mental Disorder


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.

Published by

Publié par Alexis Kinsella

Alexis Kinsella est un consultant Xebia passionné aussi bien par les problématiques frontend (web et mobile) que backend. Après de longues années passées sur les technologies Java, Alexis a fait d'iOS, Node.js et du Cloud ( AWS Certified Solutions Architect - Associate ) ses nouveaux terrains d'expérimentation lui permettant d'explorer les architectures web et mobiles ainsi que leurs problématiques associées.

Commentaire

3 réponses pour " QCon London – Developers Have a Mental Disorder "

  1. Published by , Il y a 9 ans

    Excellent billet résumant une excellente keynote. Totalement en phase avec GY.

  2. Published by , Il y a 9 ans

    Mouais, pas d’accord avec tout…

    Si tu sais utiliser correctement spring et hibernate pourquoi ne pas les utiliser pour construire un blog?

    Si tu fais que du spécifique (ex du SQL avec des spécificités Oracle + spécificités Websphere) c’est bien joli, mais déjà il va falloir apprendre ces spécificités si tu ne les connais pas, et ensuite il va falloir trouver des développeurs qui connaissent ces spécificités (si besoin d’être opérationnel immédiatement), il y en a probablement moins sur le marché que ceux qui connaissent le SQL standard et un serveur JEE standard…

    Si ton appli est petite c’est cool si tu veux passer d’une techno à l’autre y a pas de problème, mais une appli qui a 10 ans? Tu veux faire des tests de charge sous différents serveurs d’appli, mais tu peux même pas car ca tourne sous websphere. Tu peux pas comparer les perfs d’Hibernate et de Toplink. Tu peux pas comparer MySQL a Oracle.
    Je pense que beaucoup d’entre nous travaillent sur ce genre d’applis en plus…

    Alors c’est sur si tu veux monter une plateforme de blog, si tu connais pas trop le monde Java/Jee, c’est plus facile d’utiliser Play! en se basant sur leur sample de blog (encore qu’il y a du hibernate derrière…). Si tu connais deja bien spring / hibernate etc je vois pas trop le problème à utiliser Appfuse ou autre artifact.

    « 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). »
    Bin moi perso je pense que je met moins de temps à coder une petite appli à partir d’un Appfuse ou Play! plutôt qu’avec des servlets et du JDBC basic… mais bon chacun son truc après. Mettre un peu d’abstraction ça veut pas forcement dire que ça sera plus long à réaliser, surtout si tu maîtrises déjà les outils.

  3. Published by , Il y a 9 ans

    Je suis d’accord avec Sébastien Lorber.

    Au fond, Greg Young cherche à défendre une « Good enough Architecture » (et son exposé serait sans doute meilleur en mettant en avant cette notion) ; mais comme le montre Sébastien Lorber, l’abstraction n’est pas le seul facteur à prendre en compte : la maitrise des outils (qui peut être vue comme une métrique de localité) est un autre facteur important.

    Pour ma part, l’abus d’abstraction, je le vois, je l’ai vu, à travers l’abus de design patterns, et l’introduction de micro-abstractions, où, par ex, pour chaque classe définie (ou presque), une interface associée et une classe de base abstraite sont aussi créées. Cela s’apparente à une forme de micro-management.
    Dans le livre « Le mythe du mois-homme », il est fait référence brièvement à la notion de réutilisation (relativement introuvable, comme il est dit dans ce livre). Et une des personnes citées indique que l’on cherche sans doute la réutilisation à un niveau trop fin : il indiquait qu’il se verrait bien réutiliser un solveur d’éléments finis (soit un projet de taille conséquente), mais forcément qques classes de son précédent projet.

    Cela me rappelle un peu les bases relationnelles : le principe étant d’avoir (notamment) toutes les données en morceaux suffisamment petits pour que l’on s’imagine qu’il sera toujours possible de les recombiner plus tard si un besoin s’en faire sentir. Bref, tout se passe comme si ces développeurs n’avaient pas confiance dans les possibilités de refactoring.
    L’idée sous-jacente doit être que les développeurs ont sans doute peur d’enlever du code, vraisemblablement par peur de casser quelque chose, ils doivent préférer que le maximum d’éléments possibles soit présent dès le départ, de sorte que corriger un pb se fasse en espérant seulement rajouter (encore) du code : en créant une dérivation et en recombinant les éléments de base déjà là et soit disant initialement rendus les plus génériques possibles.

    Quoiqu’il en soit, Greg Young a raison de rappeler qu’il faut challenger nos habitudes, pour ne pas se fossiliser, car, au fond, la seule constante est bien « ce qui est utile aux utilisateurs ».

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Nous recrutons

Être un Sapient, c'est faire partie d'un groupe de passionnés ; C'est l'opportunité de travailler et de partager avec des pairs parmi les plus talentueux.