Grands modèles de séquence pour les activités de développement de logiciels

Sequence models for software development activities.

Publié par Petros Maniatis et Daniel Tarlow, chercheurs en informatique chez Google

Les logiciels ne sont pas créés en une étape dramatique. Ils s’améliorent peu à peu, un petit pas à la fois – en éditant, en exécutant des tests unitaires, en corrigeant les erreurs de compilation, en répondant aux critiques de code, en éditant encore et en apaisant les linters, et en corrigeant encore plus d’erreurs – jusqu’à ce qu’ils deviennent suffisamment bons pour être fusionnés dans un répertoire de code. L’ingénierie logicielle n’est pas un processus isolé, mais un dialogue entre les développeurs humains, les examinateurs de code, les rapporteurs de bugs, les architectes logiciels et les outils, tels que les compilateurs, les tests unitaires, les linters et les analyseurs statiques.

Aujourd’hui, nous décrivons DIDACT (Dynamic Integrated Developer ACTivity), qui est une méthodologie pour entraîner de grands modèles d’apprentissage automatique (ML) pour le développement de logiciels. La nouveauté de DIDACT est qu’il utilise le processus de développement de logiciels comme source de données d’entraînement pour le modèle, plutôt que seulement l’état final poli de ce processus, le code fini. En exposant le modèle aux contextes que les développeurs voient pendant leur travail, associés aux actions qu’ils prennent en réponse, le modèle apprend sur la dynamique du développement de logiciels et est plus aligné sur la façon dont les développeurs passent leur temps. Nous exploitons l’instrumentation du développement de logiciels de Google pour augmenter la quantité et la diversité des données d’activité des développeurs au-delà des travaux précédents. Les résultats sont extrêmement prometteurs selon deux dimensions : l’utilité pour les développeurs professionnels de logiciels et en tant que base potentielle pour doter les modèles de ML de compétences générales en développement de logiciels.

DIDACT est un modèle multitâche formé sur des activités de développement qui incluent l’édition, le débogage, la réparation et l’examen de code.

Nous avons construit et déployé en interne trois outils DIDACT, Comment Resolution (que nous avons récemment annoncé), Build Repair et Tip Prediction, chacun intégré à différentes étapes du flux de travail de développement. Les trois outils ont reçu des commentaires enthousiastes de la part de milliers de développeurs internes. Nous considérons cela comme le test ultime d’utilité : les développeurs professionnels, qui sont souvent des experts de la base de code et qui ont des flux de travail soigneusement affinés, utilisent-ils les outils pour améliorer leur productivité ?

• Des chercheurs ‘scindent’ les phonons pour avancer vers un nouveau type d’ordinateur quantique.
• Un capteur d’alcool mobile porté au poignet pourrait stimuler la recherche sur la consommation d’alcool.

Le plus excitant peut-être, c’est que nous démontrons comment DIDACT est une première étape vers un agent d’assistance au développement général. Nous montrons que le modèle formé peut être utilisé de plusieurs manières étonnantes, en proposant des préfixes d’activités de développeur, et en enchaînant plusieurs prédictions pour dérouler des trajectoires d’activité plus longues. Nous pensons que DIDACT ouvre une voie prometteuse vers le développement d’agents capables d’assister de manière générale tout au long du processus de développement de logiciels.

Un trésor de données sur le processus d’ingénierie logicielle

Les chaînes d’outils d’ingénierie logicielle de Google stockent chaque opération liée au code sous forme de journal d’interactions entre les outils et les développeurs, et ce depuis des décennies. En principe, on pourrait utiliser cet enregistrement pour rejouer en détail les épisodes clés de la “vidéo d’ingénierie logicielle” de la façon dont le code de Google est devenu ce qu’il est, étape par étape – une édition de code, une compilation, un commentaire, un renommage de variable, etc., à la fois.

Le code de Google est stocké dans un monorepo, un seul référentiel de code pour tous les outils et systèmes. Un développeur de logiciels expérimente généralement avec des modifications de code dans un espace de travail local géré par un système appelé Clients in the Cloud (CitC). Lorsque le développeur est prêt à regrouper un ensemble de modifications de code pour un objectif spécifique (par exemple, la correction d’un bogue), il crée une liste de changements (CL) dans Critique, le système d’examen de code de Google. Comme avec d’autres types de systèmes d’examen de code, le développeur engage un dialogue avec un examinateur de code sur la fonctionnalité et le style. Le développeur édite sa CL pour répondre aux commentaires de l’examinateur au fur et à mesure que le dialogue progresse. Finalement, l’examinateur déclare “LGTM!” (“looks good to me”), et la CL est fusionnée dans le référentiel de code.

Bien sûr, en plus d’un dialogue avec l’examinateur de code, le développeur entretient également un “dialogue” avec une pléthore d’autres outils d’ingénierie logicielle, tels que le compilateur, le framework de test, les linters, les analyseurs statiques, les fuzzers, etc.

Une illustration de la toile complexe d’activités impliquées dans le développement de logiciels : de petites actions effectuées par le développeur, des interactions avec un examinateur de code et des invocations d’outils tels que des compilateurs.

Un modèle multi-tâches pour l’ingénierie logicielle

DIDACT utilise les interactions entre les ingénieurs et les outils pour alimenter les modèles de ML qui aident les développeurs de Google, en suggérant ou en améliorant les actions que les développeurs entreprennent – dans le contexte – tout en poursuivant leurs tâches d’ingénierie logicielle. Pour ce faire, nous avons défini un certain nombre de tâches concernant les activités individuelles des développeurs : réparer une construction cassée, prédire un commentaire d’examen de code, répondre à un commentaire d’examen de code, renommer une variable, éditer un fichier, etc. Nous utilisons une formalisation commune pour chaque activité : elle prend un État (un fichier de code), une Intention (des annotations spécifiques à l’activité, telles que des commentaires d’examen de code ou des erreurs de compilateur) et produit une Action (l’opération entreprise pour répondre à la tâche). Cette Action ressemble à un mini-langage de programmation et peut être étendue pour les activités nouvellement ajoutées. Elle couvre des choses comme l’édition, l’ajout de commentaires, le renommage de variables, la mise en forme du code avec des erreurs, etc. Nous appelons ce langage DevScript .

Le modèle DIDACT est sollicité avec une tâche, des extraits de code et des annotations liées à cette tâche, et produit des actions de développement, par exemple des éditions ou des commentaires.

Cette formalisation état-intention-action nous permet de capturer de nombreuses tâches différentes de manière générale. De plus, DevScript est une manière concise d’exprimer des actions complexes, sans avoir besoin de produire l’état complet (le code original) tel qu’il serait après l’exécution de l’action ; cela rend le modèle plus efficace et plus interprétable. Par exemple, un renommage peut toucher un fichier dans des dizaines d’endroits, mais un modèle peut prédire une seule action de renommage.

Un programmeur pair de ML

DIDACT fait du bon travail sur les tâches d’assistance individuelles. Par exemple, ci-dessous, nous montrons DIDACT effectuant un nettoyage de code après que la fonctionnalité soit essentiellement terminée. Il examine le code ainsi que quelques commentaires finaux de l’examinateur de code (marqués “humain” dans l’animation) et prédit des éditions pour répondre à ces commentaires (rendues sous forme de différences).

En partant d’un extrait de code initial et des commentaires qu’un examinateur de code a attachés à cet extrait, la tâche de nettoyage pré-soumission de DIDACT produit des éditions (insertions et suppressions de texte) qui répondent à ces commentaires.

La nature multimodale de DIDACT donne également lieu à certaines capacités surprenantes, rappelant les comportements émergents à grande échelle. Une telle capacité est l’augmentation de l’historique, qui peut être activée par une incitation. Le fait de savoir ce que le développeur a récemment fait permet au modèle de mieux deviner ce que le développeur devrait faire ensuite.

Une illustration de l’achèvement de code augmenté d’historique en action.

Une tâche puissante exemplifiant cette capacité est l’achèvement de code augmenté d’historique. Dans la figure ci-dessous, le développeur ajoute un nouveau paramètre de fonction (1) et déplace le curseur dans la documentation (2). Conditionné par l’historique des modifications du développeur et la position du curseur, le modèle complète la ligne (3) en prédisant correctement l’entrée de la docstring pour le nouveau paramètre.

Une illustration de prédiction de modification, sur plusieurs itérations enchaînées.

Dans une tâche encore plus puissante augmentée d’historique, la prédiction de modification, le modèle peut choisir où éditer ensuite d’une manière qui est historiquement cohérente. Si le développeur supprime un paramètre de fonction (1), le modèle peut utiliser l’historique pour prédire correctement une mise à jour de la docstring (2) qui supprime le paramètre supprimé (sans que le développeur humain place manuellement le curseur là-bas) et pour mettre à jour une déclaration dans la fonction (3) d’une manière syntaxiquement (et – on peut le dire – sémantiquement) correcte. Avec l’historique, le modèle peut décider de manière non équivoque comment continuer la “vidéo d’édition” correctement. Sans histoire, le modèle ne saurait pas si le paramètre de fonction manquant est intentionnel (parce que le développeur est en train d’effectuer une édition plus longue pour le supprimer) ou accidentel (dans ce cas, le modèle devrait le réajouter pour corriger le problème).

Le modèle peut aller encore plus loin. Par exemple, nous sommes partis d’un fichier vierge et avons demandé au modèle de prédire successivement les modifications qui viendraient ensuite jusqu’à ce qu’il ait écrit un fichier de code complet. La partie étonnante est que le modèle a développé du code de manière progressive qui semblerait naturelle à un développeur : il a commencé par créer une structure entièrement fonctionnelle avec des importations, des indicateurs et une fonction principale de base. Il a ensuite ajouté progressivement de nouvelles fonctionnalités, comme la lecture à partir d’un fichier et l’écriture de résultats, et ajouté une fonctionnalité pour filtrer certaines lignes en fonction d’une expression régulière fournie par l’utilisateur, ce qui a nécessité des modifications dans tout le fichier, comme l’ajout de nouveaux indicateurs.

Conclusion

DIDACT transforme le processus de développement de logiciels de Google en démonstrations de formation pour les assistants de développeurs ML, et utilise ces démonstrations pour former des modèles qui construisent du code de manière progressive et interactive avec des outils et des examinateurs de code. Ces innovations alimentent déjà des outils appréciés par les développeurs de Google chaque jour. L’approche DIDACT complète les grandes avancées réalisées par les grands modèles de langage chez Google et ailleurs, vers des technologies qui facilitent la peine, améliorent la productivité et améliorent la qualité du travail des ingénieurs logiciels.

Remerciements

Ce travail est le résultat d’une collaboration pluriannuelle entre Google Research, Google Core Systems and Experiences et DeepMind. Nous tenons à remercier nos collègues Jacob Austin, Pascal Lamblin, Pierre-Antoine Manzagol et Daniel Zheng, qui se joignent à nous en tant que principaux moteurs de ce projet. Ce travail n’aurait pas pu être réalisé sans les contributions significatives et soutenues de nos partenaires chez Alphabet (Peter Choy, Henryk Michalewski, Subhodeep Moitra, Malgorzata Salawa, Vaibhav Tulsyan et Manushree Vijayvergiya), ainsi que les nombreuses personnes qui ont collecté des données, identifié des tâches, construit des produits, élaboré des stratégies, évangélisé et nous ont aidés à exécuter les nombreux aspects de cet ordre du jour (Ankur Agarwal, Paige Bailey, Marc Brockschmidt, Rodrigo Damazio Bovendorp, Satish Chandra, Savinee Dancs, Denis Davydenko, Matt Frazier, Alexander Frömmgen, Nimesh Ghelani, Chris Gorgolewski, Chenjie Gu, Vincent Hellendoorn, Franjo Ivančić, Marko Ivanković, Emily Johnston, Luka Kalinovcic, Lera Kharatyan, Jessica Ko, Markus Kusano, Kathy Nix, Christian Perez, Sara Qu, Marc Rasi, Marcus Revaj, Ballie Sandhu, Michael Sloan, Tom Small, Gabriela Surita, Maxim Tabachnyk, David Tattersall, Sara Toth, Kevin Villela, Sara Wiltberger et Donald Duo Zhao) et notre direction extrêmement favorable (Martín Abadi, Joelle Barral, Jeff Dean, Madhura Dudhgaonkar, Douglas Eck, Zoubin Ghahramani, Hugo Larochelle, Chandu Thekkath et Niranjan Tulpule). Merci !

We will continue to update IPGirl; if you have any questions or suggestions, please contact us!