Habitude vs coolitude : quand changer ses outils de travail ?

La semaine qui vient de s’écouler a été pour moi techniquement éprouvante : c’était ma première création de plate-forme de production pour un gros projet RubyOnRails… et que ce fut compliqué ! Même si Rails est a présent une technologie mature (un peu plus de 10 ans d’existence), j’ai vraiment eu l’impression de revenir 15 ans en arrière, quand le moindre serveur web demandait moult outils aux paramètres mal documentés pour parvenir à quelque chose d’à peu près propre.

Je suis pourtant particulièrement content d’être passé par là, parce que cela a aussi été pour moi l’occasion de découvrir une manière de penser radicalement différente de ce que je connaissais dont quelques méthodes assez puissantes. Mais je suis aussi ravi d’avoir attendu tout ce temps pour aller franchement sur cette technologie, alors que les gens dans le vent se sont souvent détournés de RoR et n’ont désormais plus d’yeux que pour nodejs ou Scala.

En tant que passionné, il est normal, voire sain, voire indispensable de s’intéresser à ce qui se passe en dehors de sa sphère technologique quotidienne. En tant que professionnel, il est plus compliqué d’arbitrer entre habitude des outils existants et « coolitude » du dernier truc à la mode. On peut pourtant raisonner à ce sujet comme raisonnerait un industriel classique :

  • Il faut « capitaliser » au maximum sur l’investissement fait dans une technologie particulière : plus le temps passe, plus on devient efficace avec un ensemble d’outils de référence. Des processus sont mis en place, des automatisations voient le jour, de bonnes pratiques sont connues de tous.
  • Par moment, un « saut technologique » devient nécessaire pour progresser de manière significative : c’est le moment de faire un nouvel investissement pour passer un cap.

Quand « ce saut » devient-il souhaitable ? Voici quelques éléments de décision, lorsque cela concerne une partie majeure de votre projet (un framework de développement, une grosse bibliothèque logicielle, un serveur d’application, une méthode ou un outil de gestion de projet…) :

  • Une partie de votre équipe a déjà acquis une première expérience sur la technologie en question par des proofs of concept.
  • La technologie bénéficie d’une communauté d’utilisateurs importante, a au moins 3 ans d’existence et est toujours régulièrement maintenue.
  • Vous avez une idée claire des bénéfices que va vous apporter cette technologie. Vous avez aussi une vision objective de ses défauts et des difficultés que vous allez connaître dans sa mise en oeuvre.
  • Vous avez vérifié que les bénéfices de cette nouvelle technologie ne pouvaient pas être obtenus facilement en améliorant votre manière d’utiliser vos outils habituels.
  • Le rapport bénéfice/risques de l’investissement dans cette nouvelle technologie est supérieur à d’autres investissements que vous pourriez faire dans votre environnement habituel.

Evidemment, on peut se permettre d’être un peu plus aventureux quand il s’agit de travailler sur un projet limité ou d’utiliser une simple bibliothèque logicielle.

Besoin de concrétiser ces principes ? Revenons à mon exemple initial. Je me souviens avoir commencé à me documenter sur RoR dès la fin 2005, alors que nous cherchions à améliorer l’architecture de nos projets sur technologie libre sans pénaliser la productivité à court terme. Grâce à RoR, nous avons connu prototype.js (qui était une révolution pour javascript à l’époque) et surtout CakePHP, un des tous premiers frameworks MVC PHP clairement inspirés de Rails.

Au fur et à mesure des années, plusieurs problèmes liés à l’investissement dans RoR nous en ont tenus écartés :

  • les problèmes d’exploitation et de performances des logiciels fonctionnant sous cette architecture (l’histoire de Twittr en est un excellent exemple)
  • le manque de ressources logicielles (bibliothèques, outils de développement) et humaines (formation, développeurs) pour développer dessus
  • une majeure partie de nos clients aurait été effrayée par le Ruby, langage encore peu pratiqué en France
  • les outils PHP continuaient à progresser. Nous sommes ainsi passés en 10 ans successivement de CakePHP à Zend Framework, et finalement à Symfony 2.
  • à mesure que nous progressions dans ces différentes architectures PHP, les bénéfices potentiels de Rails s’amenuisaient

Nous y sommes finalement passés quand :

  • plusieurs développeurs de l’équipe se sont mis à utiliser Ruby à des degrés divers
  • nous avons vu que nous savions maintenir en production une application Rails (en l’occurrence Redmine) assez fortement sollicitée grâce au serveur d’application Puma
  • le marché Ruby français du développement, sans être important, nous a semblé favorable (moins de projets potentiels, mais absence de concurrence « low cost »)
  • les bénéfices de RoR nous ont paru clairs : expressivité du langage, outils de l’univers Rails (HAML, Capistrano mais aussi dans une certaine mesure Sass, Compass et CoffeeScript), possibilités du meta-programming, les gemmes, certaines particularités architecturales (Active Record, les Concerns)

Naviguer au mieux entre les excès des modes et de la coolitude et ceux des vieilles habitudes n’est pas simple… j’espère que ces quelques critères vous permettront de trouver votre voie !

Publicités

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion /  Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion /  Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion /  Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion /  Changer )

w

Connexion à %s