Las prácticas de ingeniería miden la higiene de ingeniería básica: la infraestructura que hace que el cambio sea seguro. La integración continua y una suite de pruebas automatizadas son las dos prácticas con la relación documentada más sólida con la calidad sostenible, y juntas concentran la mayor parte de esta métrica.
- Categoría: Calidad de Ingeniería (60 % dentro de la categoría)
- Peso en el índice general: 12 % — la segunda métrica de repositorio con mayor peso
- Clave de la métrica:
engineering_practices
Cómo se calcula el valor
Una lista de verificación ponderada de evidencia visible de práctica:
| Componente | Peso | Evidencia |
|---|---|---|
| Flujos de trabajo de CI | 24 | configuración de integración continua presente |
| Pruebas presentes | 24 | existe una suite de pruebas en el repositorio |
| Configuración de linter | 16 | configuración de lint/formato confirmada en el repositorio |
| Hooks de pre-commit | 9.6 | configuración de pre-commit presente |
| .editorconfig | 6.4 | convenciones de editor confirmadas en el repositorio |
| OpenSSF Scorecard: CI-Tests | 20 | resultado 0–10 de Scorecard, escalado a 20 puntos |
Por qué estas cinco
- CI más pruebas forman el bucle de verificación: cada cambio se ejercita contra la suite antes de aterrizar. Su peso combinado de 60 refleja que ninguna otra práctica visible lo sustituye.
- El linting impone consistencia de forma mecánica, manteniendo la atención de la revisión en la sustancia.
- Los hooks de pre-commit y el
.editorconfigson señales menores de un proyecto que ha invertido en la ergonomía del contribuyente — los cambios llegan preverificados y con formato consistente sin importar quién los escribió.
La misma evidencia alimenta el bucle de verificación de IA: la infraestructura que permite a un contribuyente humano verificar un cambio es exactamente la que permite verificarlo a un agente de codificación con IA.
El CI-Tests de Scorecard es evidencia compartida: a diferencia de las comprobaciones locales de presencia, pregunta si los pull requests fusionados fueron verificados por la CI. También sigue siendo un componente pleno de Seguridad. La evidencia de Scorecard n/a o no disponible se excluye.
Cómo leer el resultado
- Se trata de señales de presencia — confirman que el andamiaje existe, no cuán riguroso es. Los porcentajes de cobertura y las tasas de éxito de la CI están en la hoja de ruta de la metodología.
- La falta de suite de pruebas es una de las señales negativas más fiables de toda la metodología; muy pocos proyectos disciplinados carecen de una.
Cómo mejorar el valor
- Añadir un flujo de trabajo de CI que ejecute la suite de pruebas en cada push y pull request — los dos componentes de mayor peso, a menudo alcanzables en una sola tarde.
- Confirmar en el repositorio la configuración de linter y formateador que el proyecto ya usa en local.
- Añadir una configuración de pre-commit y un
.editorconfigpara los puntos restantes.
Relacionado: documentación · bucle de verificación de IA