BC Quality: cómo auditar la calidad de tu código de Business Central

Cuando enseño cómo crear extensiones de Business Central usando agentes, una de las críticas que más se repite es siempre la misma: estamos perdiendo el control sobre lo que se genera. Y no les falta razón. Un agente puede escribir código que compila, que funciona, y que aun así arrastra errores ocultos: un `ToolTip` que falta, un patrón de rendimiento incorrecto, un evento mal manejado. 

Nada que rompa la compilación.

Microsoft ha publicado recientemente una herramienta pensada exactamente para este problema: BC Quality, un repositorio de conocimiento de buenas prácticas que permite validar objetivamente cómo está desarrollado tu código AL. Y aquí está el matiz importante: no es una herramienta pensada solo para revisar lo que generan los agentes. Sirve igual para el código que escribimos nosotros mismos.

Qué es BC Quality y qué no es

BC Quality no ejecuta nada. No compila, no analiza en tiempo real. Es una base de conocimiento formada por ficheros Markdown que documentan las buenas prácticas y patrones que debería seguir cualquier desarrollo de Business Central. La idea de fondo es sencilla pero potente: el mismo nivel de exigencia para todo el mundo. 

Las reglas que se le aplican a un desarrollador se le aplican igual a un agente. No hay trato de favor.

Es importante entender también qué queda fuera de su alcance. BC Quality no tiene sentido para aquello que el propio modelo ya sabe detectar por sí mismo: una URL en HTTP en lugar de HTTPS, o una clave puesta directamente en bruto en el código, son cosas que cualquier modelo ya señala sin necesidad de una base de conocimiento externa. 

BC Quality se centra en lo que un modelo, por defecto, no sabe que debería revisar: convenciones específicas de Business Central en dominios como rendimiento, seguridad, manejo de errores, eventos o telemetría.

Tres capas de reglas

El sistema se organiza en tres capas, aplicadas por orden de precedencia:

- Microsoft: la capa oficial, con reglas y patrones revisados por el propio equipo de Business Central.

- Community: reglas propuestas por la comunidad. Si Microsoft considera que una regla de esta capa es suficientemente sólida, puede promocionarla a la capa oficial.

- Custom: tu propia capa, vacía por defecto, donde cada partner o empresa añade sus propias normas internas además de las de Microsoft y la comunidad.

Las tres capas están activas simultáneamente. Si dos reglas entran en conflicto, se resuelven según esa precedencia.

Y como es un proyecto open source, cualquiera puede proponer nuevas reglas, siempre que aporten algo que un modelo no detecte por defecto, no simples repeticiones de lo obvio.

Cómo se pone en marcha BC Quality en un proyecto

El flujo de trabajo tiene tres pasos claros: traer el repositorio, generar un índice de conocimiento y crear un agente revisor que lo gestione:

1. Fork del repositorio

Lo primero es traer BC Quality a tu propio proyecto como submódulo de Git. Desde PowerShell, un único comando crea el submódulo dentro de una carpeta `.bcquality` y trae todo el contenido: las reglas de Microsoft, las de la comunidad y una carpeta custom vacía a la espera de tus propias normas.

2. Generar el índice de conocimiento

Con decenas de ficheros de conocimiento disponibles, revisarlos todos en cada ejecución dispararía el consumo de tokens sin necesidad. 

La solución es generar primero un índice que resume dónde está cada pieza de información. El agente revisor consulta primero ese índice y solo va a buscar el documento completo cuando realmente lo necesita.

Este índice hay que generarlo la primera vez y regenerarlo cada vez que se añadan nuevos ficheros de conocimiento, ya sea porque Microsoft publica nuevas reglas, la comunidad aporta las suyas, o porque rellenas tu propia capa custom. Como recomendación general, cada fichero de conocimiento debería mantenerse por debajo de 100 líneas, idealmente unas 50, para que siga siendo fácil de consultar y de mantener.

3. Crear el agente revisor

Con el repositorio y el índice ya listos, el siguiente paso es construir un agente cuya única fuente de verdad sea BC Quality. Este agente debe:

- Localizar el repositorio BC Quality y comprobar que existe el índice.

- Poder ejecutarse en modo fichero (revisar un archivo concreto) o en modo lote (revisar toda una carpeta, como `src`).

- Avisar cuando el volumen de ficheros a revisar sea muy alto, para evitar que la ventana de contexto del modelo pierda información por el camino, y poder ir revisando por bloques.

- Invocar el fichero de entrada del repositorio, que dirige hacia las distintas skills de lectura y ejecución según lo que se necesite en cada caso, respetando siempre la precedencia entre capas.

- Distinguir con claridad qué observaciones vienen respaldadas por la base de conocimiento y cuáles son criterio propio del modelo, sin inventarse rutas ni atribuir a BC Quality algo que no está ahí.

El resultado de cada revisión es un JSON por fichero analizado, con la fecha de la revisión, el origen de cada hallazgo y el detalle completo — sin resúmenes que recorten información.

De JSON a HTML

Un JSON por fichero es correcto para procesar, pero incómodo para leer por un usuario. Por eso en el propio flujo he generado, al final de la revisión, un pequeño script en JavaScript que recorre los JSON generados junto con el índice de conocimiento y produce un HTML legible: por cada fichero revisado, qué se ha encontrado, en qué dominio (interfaz de usuario, rendimiento, estilo...) y, sobre todo, de qué parte concreta de BC Quality procede cada observación.

Ese último punto es el que más valor aporta en la práctica: cuando el informe señala un problema, indica exactamente en qué regla de conocimiento se basa. Si una observación no tiene esa referencia, es porque procede del criterio del propio modelo y así queda marcado, nunca se presenta como si viniera de BC Quality cuando no es el caso.

Mi recomendación es incorporar esta revisión como un paso habitual, no puntual: tanto para el código que generan tus agentes como para el que escribes tú mismo. El objetivo no es sustituir el criterio del desarrollador, sino aumentarlo con una capa de verificación objetiva y consistente para todo el equipo.

Si te dedicas al desarrollo en AL, sea con agentes o sin ellos, esta es una herramienta que merece la pena incorporar a tu flujo de trabajo cuanto antes.

Puedes ver el video aquí: