Comment l'équipe Cursor utilise les règles Bugbot pour automatiser les revues de code Notamment dans les scénarios de migration de bases de données à haut risque, ils ont élaboré un ensemble de règles strictes permettant à Bugbot d'intercepter la grande majorité des opérations dangereuses avant toute vérification manuelle. La clé réside dans les « Règles Bugbot », articulées autour de trois mots clés : standardisation, automatisation et approche proactive. 🤖 Quelles sont les règles de Bugbot ? Bugbot peut être considéré comme un inspecteur de code en ligne disponible 24h/24 et 7j/7. Son fonctionnement est simple : vous stockez un fichier de règles (généralement .cursor/BUGBOT.md) dans votre base de code, décrivant vos critères de vérification en langage naturel. Lors de chaque validation de code, Bugbot analyse automatiquement le code en le comparant à ce « manuel d’inspection ». En cas d’infraction, il ajoute immédiatement un commentaire sur la ligne de code concernée ou émet un avertissement. 🛡️ Application pratique essentielle : Un « guide de prévention des catastrophes » pour la migration de bases de données L'équipe Cursor a partagé ses règles internes spécifiques pour prévenir les incidents de base de données. Elle exige que Bugbot respecte scrupuleusement les normes suivantes : 1. Opérations autorisées (sous conditions) L'ajout de nouvelles tables ou colonnes est autorisé. Cependant, les colonnes nouvellement ajoutées doivent être définies comme « autorisant les valeurs nulles » ou avoir une « valeur par défaut » afin d'éviter les erreurs lors de l'écriture de données par du code plus ancien. 2. La création d'index exige une extrême prudence : il s'agit d'une opération à haut risque. La règle impose l'utilisation du mot-clé `CONCURRENTLY` afin d'éviter le verrouillage de la table entière pendant la création de l'index, ce qui pourrait entraîner des interruptions de service. De plus, la création de l'index doit être effectuée dans un fichier de migration distinct. 3. Opérations strictement interdites : La suppression de colonnes, la suppression de tables, le renommage de colonnes ou la modification du type de données de colonnes sont strictement interdits. Ces opérations entraîneront un plantage immédiat des anciennes versions du code. Contraintes de clés étrangères : les clés étrangères sont interdites dans les nouvelles tables. L’équipe Cursor recommande de gérer les relations de données au niveau du code applicatif, plutôt que de s’appuyer sur les contraintes de clés étrangères de la base de données, afin d’éviter d’éventuels goulots d’étranglement en termes de performances. • Requêtes complexes : Les analyses complètes de tables sont interdites sur la base de données principale, de même que les opérations JOIN ou GROUP BY. Ces opérations peuvent rapidement saturer les ressources de la base de données ; il est recommandé d’effectuer l’assemblage des données au niveau de l’application. 4. Meilleures pratiques recommandées pour la sélection du type de champ : Il est recommandé d’utiliser BIGINT au lieu de INTEGER et TEXT au lieu de VARCHAR. 🚀 Applications étendues : au-delà des bases de données Outre la sécurité des bases de données, les règles de Bugbot peuvent être appliquées à de nombreux autres scénarios de développement quotidiens, aidant ainsi les équipes à maintenir un code propre et standardisé : • Gestion de la propreté du code : Vous pouvez indiquer à Bugbot : « Si vous voyez un commentaire TODO ou FIXME, vous devez vérifier s’il est associé à un numéro de ticket spécifique. » Dans le cas contraire, Bugbot laissera automatiquement un message rappelant au développeur d’ajouter le numéro de suivi ou de supprimer le commentaire, évitant ainsi l’accumulation d’un grand nombre de « tâches zombies » dans le code source. • Sécurité et conventions d'appellation : vous pouvez définir des règles pour bloquer les clés potentiellement divulguées ou imposer que certaines fonctions et le suivi des événements soient conformes aux conventions d'appellation de l'équipe. Lire le texte original
