
Interrompre un développeur de logiciels peut créer un trou noir dans son flux de réflexion alors même qu’il est rendu à un stade où la solution à un problème pointe à l’horizon. Dès lors, l’impact minimal est une rallonge du temps à consacrer à la tâche en question. Des études à ce sujet montrent en effet que suite à une interruption de 5 minutes, le regain de productivité chez un programmeur ne se produit qu’après une heure, parfois plus. Dans le cadre d’une conférence pour les développeurs du langage Ruby, le directeur technique de FutureLearn – une plateforme d’apprentissage en ligne – a livré son avis sur la question.
Toutes les « vieilles marmites » de l’univers du développement de logiciels ont été confrontées à l’ascension de ce qui peut être considéré comme l’Everest en informatique : courir après la cause d’un bogue tenace, effectuer une mise à jour majeure, migrer d’un framework à un autre, etc. Comment se comportent-elles pour que les interruptions qui sont une réalité sur le lieu de travail impacte peu (ou pas) sur leur travail ?
Le CTO de FutureLearn fait un jet préliminaire à ce propos en précisant que les break impactent beaucoup plus sur l’activité des développeurs qui optent pour la résolution de « gros problèmes » en une fois, autrement dit, ceux qui n’appliquent pas une des règles du génie logiciel qui consiste à subdiviser le problème en sous-ensembles moins complexes. Chez FutureLearn on est très probablement pro Agile puisque, par la suite, ce dernier prescrit la mise en œuvre du story mapping, une technique utilisée dans la définition macroscopique des besoins de l’utilisateur d'un produit. Le développement piloté par les tests (Test Driven Development en anglais) fait partie du flux de travail des adeptes des méthodes Agile et c’est sans surprise que le directeur technique le prescrit comme complément à la subdivision, ce, en plus d’autres dispositions relatives à l’hygiène des modifications apportées aux fichiers du projet.
Seulement, la division d’un problème en sous-ensembles relève-t-elle du trivial ? De plus, la mise en œuvre des méthodes Agile serait l’une des raisons de l’accumulation des dettes techniques de certaines entreprises. Erik Meijer, un célèbre développeur de l’écosystème .NET, s’est exprimé sur la question en 2015 et a déclaré que « l’application de l’agilité dans des projets fait beaucoup plus parler sur le code que l’écrire. » Son intervention fait suite à celle de David Heinemeier Hansson, créateur de Ruby On Rails qui, en 2014, a affirmé que les tests unitaires ne sont pas bénéfiques.
Il est manifeste que ces derniers opteraient très difficilement pour ces méthodes dans le but de minimiser l’impact des interruptions sur l’activité d’un développeur. Mais, à chacun sa position et le CTO de FutureLearn n’a fait qu’exposer la sienne.
Source : dev.to
Et vous ?





Voir aussi :



