PairProgrammer avec ChatGPT
Comme vous le savez si vous suivez régulièrement nos articles, le code que nous produisons chez AXA est exclusivement produit en Behavior Driven Development. Nous nous appuyons sur des exemples concrets fournis lors de l’Example Mapping effectué au moment où le développeur commence à traiter la demande.
Nous avons voulu étudier sur un cas concret et dans ce contexte de qualité, comment nous pourrions mettre à profit les fameuses IA émergentes permettant l’écriture de code.
L’User Story, que nous avons à traiter aujourd’hui, concerne la mise en place d’un filtre sur la liste des documents, qui sera donc prochainement disponible sur cette page : https://www.axa.fr/bibliotheque-ipid.html
Nous commençons donc par le fameux Exemple Mapping dont voici le résultat :
Les développements peuvent commencer : gherkins initiés, premières règles écrites…
Nous nous limiterons pour cet article à ces quelques règles.
Nous mettons en place l’implémentation de ces quelques tests, et conformément à la démarche BDD, ils sont tous “non passants” …
À partir de cette étape, dans une démarche BDD classique, nous devrions rentrer dans la phase d’écriture de code :
- Écrire le code pour répondre au premier test de la manière la plus simple possible.
- Rendre le premier test passant.
- “Refactorer” le code.
Boucler de cette manière sur tous les autres tests, jusqu’à ce que tous soient passants.
Mais ici, nous allons demander à Chat GPT de nous écrire directement le code.
Nous nous y connectons sur https://beta.openai.com/codex-javascript-sandbox
C’est dommage, nous ne pouvons pas utiliser les scénarios écrits en Gherkins, mais nous devons formuler notre demande. Il faudra plusieurs requêtes pour arriver à un résultat : apprendre à dialoguer, spécifier plus précisément l’attendu, trouver la bonne formulation, ou le bon artifice linguistique… (Nous sommes surement plus doués dans l’écriture de code que du français 😜) mais rapidement les premiers résultats sont là :
Écris-moi une méthode de recherche en JS, permettant de rechercher un mot dans un autre mot. Il faut que cette recherche soit insensible à la case et aux accents. Il ne faut pas tenir compte des espaces au début et à la fin du mot à rechercher. Si le mot recherché est vide ou null alors la recherche doit être positive. Utilise le français pour nommer la méthode.
Le code généré est :
Importé dans notre projet, 7 des 8 BDD deviennent passants.
Nous n’arrivons pas à (re)*trouver la bonne formule pour répondre à l’ensemble des tests. Au lieu de perdre plus de temps, nous adaptons le code source proposé.
(*) en préparation de cet article, nous étions arrivés à trouver LA bonne requête, malheureusement nous n’arrivons pas à la reproduire, ça nourrira aussi notre avis.
Suite à ces modifications, tous nos BDD deviennent passants :
Nos développements sont loin d’être terminés. Il va falloir intégrer cette méthode dans le reste de l’application, l’adapter à l’architecture du projet, créer l’UI, créer nos tests d’intégration etc… mais en termes de complexité algorithmique, cette méthode répond à la majorité des règles métiers exprimées lors de l’Example Mapping.
Le résultat est bluffant, nous avons l’impression d’être à l’aube de quelque chose qui était inenvisageable il y a encore quelques mois et qui promet de bouleverser notre quotidien et notre métier de développeur.
Mais vite, l’effet “waouh” fait place à d’innombrable questions. Même si les traiter n’est pas le sujet de cet article et qu’il nous faudra un temps certain pour digérer et maturer cette expérience, avant même de pouvoir affiner nos convictions, en voici quelques-unes :
Avons-nous vraiment gagné du temps ? Sur un cas aussi simple, clairement non.. mais est-il possible de faire plus compliqué ? Sachant que la requête pour un exemple si simple est déjà sur plusieurs lignes…
Pour un développeur, n’est-il pas plus rapide d’écrire le code que de trouver la bonne formulation pour que l’IA arrive au résultat qu’il avait en tête ?
Pourquoi avons-nous couplé le BDD à cette expérience ? Garder le contrôle sur le code généré, s’assurer que le code répond à notre besoin… Manquons-nous de confiance ? Ce couple est-il la solution ?
Devons-nous réécrire le code proposé ? Effectivement, la problématique de notre métier n’est pas tellement l’écriture algorithmique, jamais vraiment très compliqué dans notre domaine, mais sa transmission et sa pérennité. Pouvons-nous ajouter ce code en l’état à notre patrimoine ? Il ne répond pas aux principes Clean-Code, à nos guidelines… Nous allons déjà commencer par le soumettre à l’équipe en PullRequest 😜.
Nous sommes sur un code généré compréhensible, mais à terme, sur des exemples plus complexes, serons-nous toujours en mesure de comprendre le code généré ? Comment assurons-nous sa maintenance, son adaptation à un nouveau besoin ou son optimisation ? L’IA saura-t-elle nous aider à reprendre son propre code ? Une même requête ne semble pas garantir le même code. Avons-nous le droit d’utiliser le code généré et à qui appartient-il ?
Un développeur a-t-il encore besoin de savoir coder ? De comprendre ce que l’IA lui fournit ? Si le code généré devient une boite noire, comment saurons-nous déterminer qu’elle ne fait que ce qu’elle doit faire ?
Sera-t-il possible de générer le code directement depuis des scénarios Gherkins, ou même simplement en reprenant le corps d’une User Story ? Utiliserons-nous comme un stack overflow amélioré, pour partager nos solutions à des problématiques très spécifiques ? Deviendrons-nous des développeurs “améliorés” ?
Qu’en est-il des versions payantes ou prochaines de ces IA qui nous promettent de traiter l’ensemble complet des sources d’un projet ?
…
Nous nous arrêterons là, cela nous promet déjà beaucoup d’autres tests et d’échanges : en tout cas le sujet promet d’être passionnant 😜
