Automatisation des avis de code à l’aide d’Openai et de GitHub

L’état des revues de code dans le paysage de développement d’aujourd’hui:

Dans le monde du développement des logiciels en évolution rapide d’aujourd’hui, l’IA a fait des progrès remarquables. Il peut écrire du code, déboguer les erreurs et même aider les architectures de conception. Mais soyons honnêtes, nous ne sommes pas tout à fait à un point où l’IA peut prendre le contrôle de l’ensemble du processus de développement. Les développeurs humains sont toujours essentiels, non seulement pour leurs compétences de codage, mais parce qu’ils apportent quelque chose que l’IA ne peut pas reproduire (encore): le contexte, l’intuition et une compréhension approfondie du problème commercial qu’ils résolvent.

Cela dit, même les développeurs expérimentés font des erreurs. Dans des délais serrés et avec une complexité de code croissante, les choses se déroulent, les bogues logiques, les problèmes de performances ou même les lacunes de sécurité. C’est pourquoi les avis de code sont si critiques. Ils agissent comme une deuxième paire d’yeux avant que tout code ne soit fusionné. En règle générale, des plates-formes comme GitHub sont utilisées pour cela. Un développeur soulève une demande de traction (PR) et un coéquipier passe en revue les modifications avant d’être approuvées. Vous trouverez ci-dessous le fonctionnement du processus actuel.

Processus actuel de révision du code

Mais les avis de code eux-mêmes ne sont pas parfaits. Les examinateurs peuvent être surchargés de tâches, pas familiers avec la partie spécifique de la base de code, ou manquer quelque chose. Dans les équipes qui gèrent des dizaines de RP par jour, donner à chacun d’eux suffisamment l’attention est difficile. Et c’est là que l’IA peut donner un coup de main.

Où une IA générative s’intègre

L’IA générative – comme les modèles d’Openai peuvent servir d’assistant utile pendant le processus d’examen du code. Pas en remplacement des critiques humains, mais comme une couche supplémentaire de perspicacité. Imaginez une IA qui regarde instantanément votre RP, résume les changements, souligne les problèmes et suggère de meilleures approches, toutes quelques-unes après l’ouverture du RP.

Voici comment cela aide:

• Chaque PR obtient au moins un examen de base.
• Les examinateurs peuvent se concentrer sur la logique complexe ou les règles métier, plutôt que sur les fautes de frappe ou les cas de bord manqué.
• Les développeurs obtiennent des commentaires plus rapides, ce qui signifie des itérations plus rapides et moins de bogues.

Dans ce blog, je vais vous montrer comment créer un pipeline de revue de code automatisé en utilisant:

• Actions GitHub (pour déclencher des revues lorsqu’un PR est augmenté)
• Python (pour extraire les modifications de code et communiquer avec Openai)
• Openai (pour générer la revue)
• Commentaires GitHub PR (pour publier les commentaires de l’IA là où le développeur en a besoin)

Aperçu de l’architecture

Voici un schéma d’architecture simple montrant comment tout se connecte:

Flux de travail de revue de code automatisé

Commencer – ce dont vous aurez besoin

Un référentiel GitHub

Vous pouvez utiliser n’importe quel repos github existant ou en créer un nouveau pour cela. L’IA examinera les PR futurs soulevés dans ce référentiel.

Un compte Openai

Si vous n’en avez pas encore un, créez-le ici: Plate-forme Openai Alors:

• Vérifiez vos crédits gratuits disponibles ici.
• Si vos crédits sont épuisés, ajoutez un mode de paiement (minimum 5 $) ici.
• Générez une clé API et enregistrez-la dans votre dépôt GitHub sous:
  Paramètres → Secrets et variables → Actions → Ajouter un secret → OpenAI_API_KEY

Comment ça marche – étape par étape

1. Le développeur soulève un PR

Il s’agit de votre flux de développement habituel, une fonctionnalité ou une branche BugFix est poussée et un PR est créé contre la branche principale.

2. L’action GitHub est déclenchée

GitHub vous permet d’exécuter des workflows automatisés sur des événements comme la création de relations publiques. Vous pouvez configurer ceci en ajoutant un fichier yaml sous .github / workflows / ai-review.yml.

Le workflow fait ce qui suit:

• Vérifie le code
• Installe les dépendances (comme le client Openai Python)
• Exécute un script Python qui déclenche la critique

3. Obtenez le git diff

Le script Python compare la branche actuelle avec la cible (généralement principale) pour savoir ce qui a changé:

subprocess.check_output(["git", "diff", "origin/main...HEAD"], text=True)

Cela nous donne les modifications exactes apportées par le développeur.

4. Envoyez le diff à Openai

Nous envoyons ce diff à OpenAI à l’aide d’une API de complétion de chat, comme ceci:

client.chat.completions.create(
    model="gpt-3.5-turbo",
    messages=[
        {"role": "system", "content": "..."},
        {"role": "user", "content": diff}
    ]
)

Nous utilisons le rôle du système pour dire à l’AI quel type de réponse nous attendons. Dans ce cas, une revue de code détaillée. Voici un exemple d’invite:

"You are a senior software engineer and an expert code reviewer. "
"When provided with code diffs, you will perform a detailed and structured review. "
"Break your feedback into the following sections:"
"1. Summary of Code Changes – Describe in simple terms what the changes are trying to do."
"2. Code Quality Issues – Point out bugs, code smells, or inefficiencies."
"3. Suggestions for Improvement – Offer clear, better alternatives (with code snippets) for problematic parts."
"4. Overall Assessment – Summarize how good or bad the changes are and if they meet clean code standards."
"Be constructive, concise, and professional."

Le message utilisateur est le code réel diff.

Pourquoi GPT-3.5 Turbo?
Il est rapide, abordable et étonnamment bon pour repérer des bogues et recommander un meilleur code. Si vous voulez des informations encore plus profondes, vous pouvez passer à GPT-4 ou GPT-4O – mais pour les critiques de base, 3.5 est génial.

5. Post Review Retour au PR

Enfin, nous prenons la réponse d’Openai et le publions comme un commentaire dans le PR à l’aide de l’API REST de GitHub et de Github_token secrète.

Exemple: à quoi ressemble une revue de code alimentée par AI

Pour voir cela en action, voici un exemple réel d’une revue de code automatisée effectuée par OpenAI.

Nous avons créé un exemple de référentiel GitHub qui montre comment fonctionne cette configuration: 🔗 Voir le dépôt sur github

Dans ce repo, nous incluons un extrait SQL délibérément défectueux pour tester comment OpenAI répond lors d’une demande de traction:

-- No so good SQL Code for Review
SELECT * 
FROM customers 
WHERE status="active"
AND register_date > '2022-01-01'
OR status="inactive"
ORDER BY customer_name;

Lorsque ce code est engagé et qu’un PR est augmenté, OpenAI analyse automatiquement les modifications et publie un commentaire de révision directement dans la demande de traction, comme ceci:

Résumé des modifications de code

Comme indiqué dans le commentaire ci-dessus, le réviseur de l’IA fournit des informations structurées et précieuses, notamment:

• Résumé clair des changements: Il a reconnu l’ajout du script de révision AI, du flux de travail GitHub et d’un exemple de fichier SQL.
• Commentaires de la qualité du code: Il a souligné les lacunes de sécurité, manquant une gestion des erreurs et suggéré des noms de variables plus descriptifs.
• Analyse précise de la requête SQL: Il a correctement identifié une faille logique dans la requête SQL: la condition

WHERE status="active" 
AND register_date > '2022-01-01' 
OR status="inactive"

a été signalé en raison de parenthèses manquantes. L’IA a compris que cela pourrait entraîner un filtrage incorrect, une erreur courante dans SQL où la priorité de et et ou n’est pas correctement contrôlée. Cela montre sa capacité à raisonner par la syntaxe et la logique dans SQL, pas seulement les problèmes au niveau de la surface.

• Suggestions exploitables: De l’amélioration des noms de variables à la correction de la logique SQL, il a offert des correctifs pratiques et prêts à l’emploi.
• Évaluation professionnelle: L’IA a fourni une revue équilibrée, mettant en évidence l’innovation tout en recommandant des améliorations pour rendre la solution plus robuste.

Ce type de rétroaction améliore non seulement la qualité du code, mais aide également les développeurs à apprendre de meilleures pratiques au fil du temps sans attendre que les examinateurs humains interviennent.

Adapter la réponse selon les besoins:

Pour nous concentrer uniquement sur la révision du code SQL, nous pouvons simplement réviser l’invite envoyée à OpenAI. En adaptant les instructions pour limiter la portée de l’examen à la logique SQL et aux meilleures pratiques, nous nous assurons que les commentaires restent ciblés et pertinents.

Vous trouverez ci-dessous l’invite révisée utilisée:

"You are a senior SQL expert and code reviewer. "
"When given a SQL query, provide a detailed and structured review focusing only on the SQL logic. "
"Break your feedback into the following sections:"
"1. SQL Issues Identified - List any logic errors, performance bottlenecks, poor formatting, or bad practices."
"2. Suggested Fixes - Provide the corrected SQL query, with improvements for readability, logic correctness, or efficiency."
"3. Brief Explanation - Explain why the original query needed changes and what the new version improves."
"Be concise, clear, and assume the reviewer has working SQL knowledge."

Et voici le commentaire de révision généré par OpenAI en réponse:

Problèmes SQL

Cela montre à quel point nous pouvons adapter facilement les invites à répondre aux exigences de révision spécifiques comme SQL, Python ou même la documentation.

Emballage

Cette configuration ne remplace pas les critiques humains, il les aide. Il garantit que chaque RP, aussi petit ou précipité, obtient une revue constante et automatisée qui ajoute de la valeur réelle. Les examinateurs peuvent se concentrer sur ce qui compte le plus. Les développeurs obtiennent des commentaires instantanément. Les équipes réduisent les erreurs et renforcent la confiance dans leur base de code.