Cómo el equipo de Cursor utiliza Bugbot Rules para automatizar las revisiones de código Especialmente en escenarios de migración de bases de datos de alto riesgo, han desarrollado un conjunto de "reglas férreas" que permiten a Bugbot interceptar la gran mayoría de las operaciones peligrosas antes de la revisión manual. La clave son las "Reglas de Bugbot", con varias palabras clave: estandarización, automatización y desplazamiento a la izquierda. 🤖 ¿Qué son las reglas de Bugbot? Puedes imaginar a Bugbot como un "inspector de código" en línea disponible las 24 horas, los 7 días de la semana. Su funcionamiento es sencillo: almacenas un archivo de reglas (normalmente .cursor/BUGBOT.md) en tu código base, donde escribes tus criterios de revisión en lenguaje natural. Al enviar código nuevo, Bugbot lo analiza automáticamente con este "manual de inspección". Si encuentras una infracción, comenta inmediatamente la línea de código o emite una advertencia. Aplicación práctica básica: una "Guía de prevención de desastres" para la migración de bases de datos El equipo de Cursor compartió sus normas internas específicas para prevenir incidentes en la base de datos. Exigen que Bugbot cumpla estrictamente con los siguientes estándares: 1. Operaciones permitidas (con condiciones) Añadir nuevas tablas o columnas: Está permitido. Sin embargo, las columnas recién añadidas deben configurarse como "nullables" o tener un valor predeterminado para evitar errores al escribir datos en código antiguo. 2. La creación de índices requiere extrema precaución: Esta es una operación de alto riesgo. La regla exige el uso de la palabra clave `CONCURRENTLY` para evitar bloquear toda la tabla durante la creación del índice, lo que podría causar interrupciones en el funcionamiento del sistema. Además, la creación del índice debe realizarse en un archivo de migración independiente. 3. Operaciones estrictamente prohibidas: Se prohíbe estrictamente eliminar columnas, eliminar tablas, renombrar columnas o cambiar el tipo de datos de las columnas. Estas operaciones provocarán un bloqueo instantáneo de versiones anteriores del código. Restricciones de clave externa: Se prohíbe el uso de claves externas en las tablas nuevas. El equipo de Cursor recomienda gestionar las relaciones de datos a nivel de código de la aplicación, en lugar de depender de las restricciones de clave externa de la base de datos, para evitar posibles cuellos de botella en el rendimiento. • Consultas complejas: Se prohíben los escaneos completos de tablas en la base de datos principal, así como las operaciones JOIN o GROUP BY. Estas operaciones pueden agotar fácilmente los recursos de la base de datos; se recomienda realizar el ensamblaje de datos en la capa de aplicación. 4. Mejores prácticas recomendadas para la selección del tipo de campo: Se recomienda utilizar BIGINT en lugar de INTEGER y TEXT en lugar de VARCHAR. 🚀 Aplicaciones extendidas: más allá de las bases de datos Además de la seguridad de la base de datos, las reglas de Bugbot se pueden aplicar a muchos otros escenarios de desarrollo cotidianos, lo que ayuda a los equipos a mantener un código limpio y estandarizado: Gestión de la limpieza del código: Puedes indicarle a Bugbot: "Si ves un comentario TODO o FIXME, debes comprobar si está asociado a un número de problema específico". De lo contrario, Bugbot dejará automáticamente un mensaje recordando al desarrollador que añada el número de seguimiento o elimine el comentario, evitando así que se acumulen muchas tareas innecesarias en el código. • Seguridad y convenciones de nomenclatura: puede establecer reglas para bloquear claves potencialmente filtradas o exigir que funciones específicas y el seguimiento de eventos se ajusten a las convenciones de nomenclatura del equipo. Lea el texto original
