Chez enioka Haute Couture, nous avons commencé à proposer des formations depuis quelques temps. Fidèles à notre ADN, nous nous concentrons sur les pratiques du génie logiciel plutôt que sur un outil, un framework ou une API en particulier. C’est pourquoi nous proposons des formations sur des sujets tels que l’architecture logicielle, le refactoring, la prise en main de code legacy, le développement piloté par les tests (TDD), les relectures de code, etc.
Par ailleurs, toutes les équipes n’ont pas les mêmes besoins. Certaines préfèrent quelques jours intensifs au cours d’une même semaine, d’autres préfèrent des sessions plus petites sur une période plus étendue. C’est pourquoi nos formations sont conçues pour être flexibles. Elles peuvent être adaptés pour construire une session de plusieurs jours, ou bien se présenter sous la forme de sessions d’une heure.
J’espère que tout cela vous semble intéressant (en tout cas, je trouve ça bien). Alors pourquoi en parler maintenant ? S’agit-il d’une simple annonce publicitaire ? Eh bien… pas vraiment.
Il s’est passé quelque chose pendant que nous travaillions sur nos offres de formation. Il y a presque trois ans, GitHub a annoncé GitHub Copilot. À l’époque, il ne s’agissait que d’une technical preview. Mais depuis, on assiste à une course aux armements dans le domaine des large language models (LLM). Qu’on le veuille ou non, l’IA générative est là pour rester et les assistants de code basés sur de tels modèles sont de plus en plus utilisés.
Je ne suis pas de ceux qui prétendent que ces modèles et assistants vont remplacer nos emplois de développeurs. Je ne pense pas non plus qu’ils vont doubler la productivité des développeurs au quotidien. Néanmoins, ils auront nécessairement un impact sur notre façon de travailler et sur le code produit. En gardant un œil sur les pratiques de développement, je m’inquiète moins de la disparition des emplois de développeurs que par une baisse de la qualité du code produit.
En effet, les premières études indiquent que les assistants de code, lorsqu’ils sont introduits de manière non contrôlée ont tendance à faire baisser la qualité du code et à augmenter le nombre de problèmes de sécurité introduits. Il est intéressant de noter que les principaux facteurs mis en évidence sont liés au comportement des développeurs. Ce qui signifie qu’avant d’attendre un nouvel outil magique qui coderait parfaitement (spoiler : cela n’arrivera pas), nous devrions plutôt améliorer la façon dont nous introduisons et utilisons ces outils.
Ce qui me ramène aux [formations enioka Haute Couture]. Dans cette nouvelle ère, nous devons tenir compte des assistants de codage lors de nos formations. Cela concerne tous les sujets que j’ai mentionnés précédemment. Il y a maintenant une question lancinante pour toutes nos pratiques de développement logiciel : à quels moments un assistant de codage est-il le bon outil pour la tâche à accomplir ?
Si vous pratiquez le TDD ou essayez de mieux l’appliquer, est-ce une bonne idée de demander à l’assistant de codage d’écrire les tests à votre place ? Peut-être pas… puisque c’est là que vous prenez des décisions importantes en terme de conception, il est probable que vous souhaitiez rester aux commandes. En revanche, il peut être utile de générer le code qui doit passer les tests.
Si vous avez affaire à une base de code existante qui doit être modernisée, pour quelle partie du processus l’assistant de codage vous permettra-t-il d’être plus rapide ? Pour mettre à jour le code vers une version plus récente du langage ou des dépendances ? Pour extraire des modules et des fonctions plus clairs ? Pour rédiger des approval tests afin de sécuriser cette modernisation ?
Il y a beaucoup d’autres questions de ce type… et vous pouvez explorer les réponses avec nous lors de l’une de nos sessions de formation. Nous continuerons à parler de TDD, de code hérité… mais avec une touche en plus !
Et bien sûr, comme tout autre outil, ce que nous proposons n’est pas spécifique à une solution donnée. Vous utilisez GitHub Copilot ? Codeium ? Un modèle spécifique en interne ? C’est parfait, nous en tiendrons compte lors de la formation pour l’adapter autant que possible aux développeurs et à leur contexte.