Accompagnez vos développeurs

Depuis quelques temps, je lis beaucoup de documentations sur la gestion de projet avec Scrum, le Lean Development, l’eXtreme Programming et l’agilité. Je suis toujours ravi de voir qu’une des bases de ces concepts est de fournir un produit avec une structure technique de qualité. Qualité de l’architecture, qualité de la documentation, qualité du code.

Mais chaque fois que j’arrive dans une nouvelle entreprise, je suis toujours étonné de la qualité de ce qui a été conçu.

  • On parle d’architecture, mais il n’y a pas d’architecte.
  • On parle de documentation, mais il n’y a pas de document.
  • On parle de logiciels, mais lorsqu’on étudie le code, on voit clairement le concept principal, « je code vite, je code pour que çà marche, le reste (bon code, commentaires, syntaxe généralisée) on verra plus tard (c’est à dire : jamais)« .

Je crois avoir presque tout vu :

  • Des classes avec le nom du développeur, très pratique quand il ne fait que passer sur le projet,
  • Du code très très technique qui marche à moitié, mais dont on ne sait pas grand chose car il n’y a aucun commentaire, aucune doc et puisque le développeur est parti depuis de nombreuses années,
  • Du code de base, mais sans aucun commentaire, aucune règle, aucune organisation,
  • Des méthodes très longues (+ de 2000 lignes),
  • Du code avec plus de codes commentés que de codes exécutés,
  • Des classes avec des méthodes sans paramètres, les membres de classe sont utilisés comme paramètres, imaginez l’enchevêtrement lorsque le code n’est pas exécuté dans le bon sens,
  • Des membres de classes définis par le constructeur mais jamais utilisés, pratique lorsqu’on se dit que la classe pourrait répondre à nos attentes avec un paramètre mais qu’il n’en est rien,
  • Des projets où tous les fichiers (pages web, classes, javascript, images, fichier de properties…) sont à la racine du projet, aucun dossier, super pour rechercher ses fichiers,
  • Des classes avec l’ensemble de toutes les valeurs utilisées éparpillées dans le code, en dur, répétées des dizaines de fois. Vous changez le nom d’une valeur, il faut le changer dans 10 classes différentes, imaginez lorsque vous travaillez sur un fichier xml et que l’ensemble des balises est répété à plusieurs endroits, comprendre le code, le modifier ou le réutiliser sont un vrai bonheur,
  • Des logs en dur avec System.out partout, avec marquez « toto3, « test1 » ou « passe par ici », « passe par là »,
  • Des centaines de lignes de code copier-coller, avec une ou deux lignes qui changent, comme ça, pour corriger les bugs, ce sera le bonheur,
  • Des développeurs qui, pour adapter leur projet à un process particulier, préfèrent créer une nouvelle branche et faire les quelques modifications qui s’imposent, plutôt que de faire fonctionner leur esprit afin d’ajouter un paramètre dans une méthode,

Ce ne sont que quelques extraits, et ils ne sont pas réservés à des développeurs junior, bien au contraire.

La seule société où j’ai pu travailler sur un code de qualité remonte à ma première expérience en Suisse. Certes les Suisses sont connus pour la qualité de leur travail, mais on peut dire qu’ici le code (et le développeur) était traité avec le respect qui lui est du. Règles de développement, commentaires, documentations, process strict, packages, rôles… Débuter dans cette société m’a permis d’intégrer un point essentiel que tout développeur devrait maitriser. Le développement de qualité.

Et lorsque vous croisez un ‘mauvais’ développeur (mauvais dans le sens où il ne respecte pas de standard en développement, commentaires, organisation), vous ne pouvez pas le blâmer. S’il n’a pas été éduqué pour faire du bon code, il faudrait qu’il prenne sur lui afin d’apprendre seul, ce qui n’est jamais facile.

Qui blâmer alors si on ne peut pas blâmer le développeur ?

Facile, son supérieur direct. Le chef d’équipe ou le chef du projet. On entend souvent qu’un chef d’équipe ou un chef de projet informatique n’a pas besoin de connaitre l’informatique pour être un bon chef. Faites moi rire, vous en connaissez beaucoup des chefs IT qui n’ont jamais fait de développements ? Je n’en ai jamais croisé.

Son rôle est certes de gérer l’équipe ou le projet mais il est également de s’assurer de la qualité de ce qui est produit et pas seulement que le produit répond aux attentes ou non. Ce serait un peu trop facile.

Alors oui, c’est long, oui, c’est fastidieux, oui, il faut répéter, insister, vérifier, re-vérifier. Mais si vous voulez des développeurs de qualité, il vous faut fournir un travail de qualité. Si vous ne faites pas ce travail avec vos développeurs en controlant, expliquant pourquoi vous voulez ceci comme ca, et pas autrement, vos développeurs ne seront jamais de bons développeurs et vous aurez des difficultés par la suite à faire avancer votre projet. Prenez le temps maintenant, vous en gagnerez beaucoup plus tard.

Accompagnez vos développeurs !!!

Publicités

3 Réponses to “Accompagnez vos développeurs”

  1. Ludovic G. Says:

    Tout à fait d’accord avec toi 😉

  2. Serge T. Says:

    La vérité !

  3. BokC Says:

    Je suis d’accord avec toi sauf que souvent le chef de projet/manager ne sait meme pas ce qu’est un code de qualité.


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 )

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 )

Photo Google+

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

Connexion à %s

%d blogueurs aiment cette page :