Mix-it 2014 : Retour sur I want to be an efficient developper

Une des conférences à laquelle j'ai assisté était celle animée par Quentin Adam @waxzce CEO de clever_cloud.

Cette conférence regroupe un ensemble de bonne pratiques pour permettre à un développeur d'améliorer sa production et sa concentration sur sa valeur ajoutée sur un projet. Le speaker commence par poser le contexte dans lequel il évolue (PaaS) et nous explique que par une approche par l'exploitation des différentes applications hébergée et opérées par sa société ils ont pu identifier des bonnes pratiques permettant une meilleur productivité et la livraison d'applications performante.

Le premier point soulevé est que les développeurs sont les créatifs dans une société IT. En effet ceux sont eux qui apportent les solutions aux problèmes que souhaitent résoudre les applications d'aujourd'hui. Et à ce titre ce qui est important n'est pas forcément l'idée ni la société en tant qu'entité mais les gens qui la composent! Un retour à la valeur de l'humain en somme. Il découle de ce constat que de manière générale le meilleur moyen de rendre des développeurs efficaces et productifs c'est de les rendre "HEUREUX". En effet un développeur épanouis sera plus productif et produira un code de bien meilleur qualité qu'un développeur démotivé ou travaillant par contrainte. Il apparaît donc important de prendre en compte différents point pour que nos équipes soit heureuses :

• Il faut optimiser l'environnement de travail et les process pour favoriser le développement. Les process ne doivent pas être conçus avec un vision reporting / contrôle mais plutôt avec l'objectif de facilité la production des développeurs. Des développeurs aidés par les process et dans un bon environnement de travail seront heureux et donc meilleurs!
• Il faut s'inspirer de l'open-source en effet le monde de l'open-source est composé majoritairement de gens qui codent des applications parce qu'ils en ont envie!! C'est cette envie qui doit être apportée sur nos projets.
• Un autre point important est de donner du sens à son travail, il faut que le développeur ait la sensation que son travail sert et apporte quelque chose, qu'il réponde a un besoin un résolvant un problème.

L'environnement dans lequel évolue l'équipe doit lui permettre d'être fière du travail accompli. Il doit permettre de produire facilement du code et surtout de le montrer facilement. Pour cela il faut :

• Releaser tôt et souvent (tiens ça ressemble à l'agile ça ;-) ).
• Se focaliser sur l'apport de valeur, produire pour 'rien' n'est pas motivant!
• L'intégralité de l'équipe doit être capable de déployer rapidement et proprement l'application. Idéalement un poste de travail devrait être capable d'héberger l'application dans son ensemble et ce sans passer 3 jours à configurer l'environnement.
• Limiter dans le temps la durée de vie d'une demande de validation, par exemple partir du principe que sans réponse négative à un proposition de choix technique au bout d'un certain délais, la solution proposée est réputée validée et donc implémentée. Cette démarche responsabilise l'équipe quand aux choix faits (le promoteur d'une idée ne peut se défausser sur un validateur et vice-versa).
• On doit viser la possibilité de déployer plusieurs fois par jours. Pour cela on peut découper une application en modules indépendants cela amène à limiter la base de code de chaque application, les modules sont vus comme des services par les autres modules (on tend alors vers un système événementiel ce qui amène de la robustesse et la possibilité de scalabiliser l'application).
• Veiller à utiliser les bons outils pour les tâches à effectuer (éviter le syndrome j'ai un marteau donc tous les problèmes sont des clous ...).
• déployer de façon asynchrone et pour cela éviter autant que possible les environnements spécifiques / spécialisés (être capable de cloner les environnements).

Tout ceci ressemble fortement au retour du SOA mais finalement ce n'était peut être pas une mauvaise approche ;-).

Un dernier point auquel on doit veiller (en tout cas que j'ai retenu de cette conf!) est la viabilité de la base de code et son vieillissement. En effet comme toute chose une base de code prend de l'âge et peu à peu la décrépitude la gagne. Pour enrailler les ravages du temps il faut se donner la possibilité (le speaker parle de pouvoir ) de changer le code. Le refactoring doit être autorisé, encouragé même! En effet pourquoi s'obstiner à patcher n fois un code, alors que la connaissance acquise par sa maintenance permettrait de le ré-écrire sous une forme plus propre et plus performante. En effet les écueils ayant amené à patcher le code sont connus et seront directement pris en compte lors de la ré-écriture amenant une meilleur conception de la solution et du coup une solution certainement plus maintenable et plus performante. Utiliser un bon outil de versionning permet en plus d'avoir la liberté de "jeter" n'importe quel bout de code en ayant la garantie de pouvoir revenir en arrière si on sent qu'on se fourvoie et là GIT rocks!!! Il faut aussi veiller a éviter de réinventer la roue quand de bonne solution existe déjà (le protocole HTTP par exemple apporte de nombreuses fonctionnalités trop souvent ignorées), outiller le code pour viser une meilleur productivité et limiter le volume de code (plus votre base de code est petite moins il y a d'endroit où un bug peut se cacher!!) et il faut se focaliser sur la lisibilité du code et éviter les optimisations précoces!

En conclusion (enfin dirons certains) je dirais que cette conférence remet le focus sur le pragmatisme et sur les développeurs. Notre métier et de produire du code qui apporte de la valeur ajoutée à l'application et qui répond à un besoin. Nous devons pouvoir être fiers de notre travail et avoir envie de le montrer, et non pas travailler pour remplir une ligne de reporting ou pour remplir notre CV de techno sexy mais au final n'apportant rien.

Merci à Quentin pour cette conf pleine de vie et avec des morceaux de vécu dedans (ça j'ai beaucoup aimé), pour son langage directe et franc (ça j'ai adoré) et pour cet éclairage sur le développeur qui ma foi serait une vraie plus values pour certains décideurs!

Sur ce je m'en vais essayer Lombok histoire d'arrêter peut-être d'écrire des K-lignes de getters and setters dans mes futurs apps.

See you soon (or not :-) ).

Les slides : http://fr.slideshare.net/quentinadam/mixit-efficient