Un trop grand nombre de choix impacte-t-il la productivité ?
Un trop grand nombre de choix impacte-t-il la productivité ?
Selon un senior : ceci paralyse les développeurs
Dans un billet de blog, Jason Gorman, le fondateur de Codemanship, s’intéresse à la productivité des développeurs, et plus particulièrement sur la relation entre les standards de code restrictifs et la productivité.
L’origine de ce billet remonte à il y a plus d’un mois, lorsque Gorman eut une discussion avec un de ces clients dont l’équipe avait mis au point un système leur permettant de contrôler la qualité de leurs codes avant de son intégration. Le fonctionnement de ce système de contrôle est assez simple : il détecte les commits qui introduisent de nouveaux threads dans le code et les places dans une file d’attente pour être jugées par l’équipe. Si les autres développeurs de l’équipe pensent que le thread introduit n’est pas nécessaire, ils peuvent refuser d’intégrer ce commit au code source de la solution.
La raison pour l’ajout d’une telle restriction est que le code introduisant du multithreading couterait plus cher à l’équipe : « nous avons tous remarqué ce que la complexité inutile fait à notre code. Il le rend plus difficile à comprendre, plus difficile à modifier et plus susceptible de contenir des erreurs. Le multithreading ajoute sans doute la forme la plus pernicieuse de complexité, la création d'une explosion dans les manières que peut avoir notre code pour mal fonctionner ».
Toutefois, ce qui intéressait Jason Gorman n’était pas les effets du multithreading sur la complexité du code, mais plutôt « l'impact que peuvent avoir les standards de codage rigoureusement appliqués sur la productivité ». Il affirme que « les normes sont des règles, et les règles sont des contraintes », et les contraintes limitent le nombre de solutions possibles pour résoudre un problème, ce qui est bénéfique pour l’équipe de développement selon lui, puisque les « les programmeurs sont paralysés lorsqu’il y a trop de choix ». Il argumente son avis en citant un exemple du quotidien où il est plus facile de cuisiner un plat se limitant aux seuls ingrédients disponibles chez soi que de considérer la liste des ingrédients disponibles dans le super marché. « Sur le long terme, nous nous limitons à éviter d'être submergés par le choix dans le feu de l’action, quand les décisions peuvent avoir besoin d'être prises rapidement. Mais nous nous limitons à une bonne sélection de choix - ou devrais-je dire, une sélection de bons choix - qui va marcher dans la plupart des situations. Tout comme Einstein limitait sa garde-robe pour qu'il puisse passer [plus de temps] à inventer la gravité ou quoique ce fut ce qu'il faisait ».
Mais il ne faut, selon lui, pas tomber dans le piège de faire de « l’analyse de nouvelles solutions » ainsi que « l’essai de nouveaux langages / plateformes / outils » une activité explicite : ceci aurait « l'effet indésirable de créer une option supplémentaire pour les gestionnaires non techniques. Tout comme le refactoring, il est probablement plus sage d’enlever cette tâche de leur attribution ».
Il suggère de retarder cette découverte de nouvelles solutions jusqu’au moment où on trouve que notre boîte à outils est trop limitée pour faire une certaine tâche. Une fois arrivé ce moment, « nous devrons improviser comme nous le faisons toujours » avant de passer au mode Recherche et Développement : « Dans l'Extreme Programming, nous appelons cela les "spikes" ». Le but est d’éviter de perdre du temps dans les choix alors qu’on peut avoir « une très bonne solution que nous pourrions appliquer immédiatement ».
Source : Codemanship
Et vous ?
Êtes-vous d’accord avec l’avis de Jason Gorman ?
Répondre avec citation
Envoyé par Matthieu Vergne
Partager