¿Deberían imponerse los estándares / estilo de codificación mediante el servidor de integración continua que ejecuta herramientas de análisis estático (por ejemplo, PMD, StyleCop / FxCop) y falla la compilación si no se siguen los estándares? ¿Qué tipos de reglas no deben usarse para fallar la compilación?
Respuestas:
Los estándares de codificación deben estar allí por una razón ... y se debe verificar el incumplimiento.
Sin embargo, no todas las violaciones deben considerarse errores, al igual que no todas las violaciones de compilación. Donde trazas la línea tiene que ser una empresa y una decisión de herramienta.
Por ejemplo, MISRA define sus reglas como Requerido y Asesor ... Sugeriría que los Avisos permitirían que la compilación continúe.
No es completamente desconocido y sabrá si funcionará para usted solo probándolo. Hay algunos pasos que podría tomar antes de eso.
Primero, el equipo debe decidir sobre los estándares juntos. Luego, herramientas como ReSharper deberían usarse para informar a los desarrolladores si no cumplen con los estándares. Hacer revisiones por pares en cada tarea podría ayudar aún más.
Después de que se hayan tomado esos pasos, se podría considerar poner controles estándar de codificación al servidor CI. Sin embargo, aún se debe considerar si es aconsejable tener un descanso de compilación para no cumplir con los estándares de codificación. El riesgo es que tendrá muchas construcciones rotas que podrían diluir el significado de la construcción rota.
En lugar de romper la compilación, puede ejecutar las herramientas y hacer que creen informes. Si la violación de códigos estándar parece estar aumentando, puede reunir al equipo y descubrir por qué está sucediendo.
¿Deberían imponerse los estándares / estilo de codificación mediante el servidor de integración continua que ejecuta herramientas de análisis estático (por ejemplo, PMD, StyleCop / FxCop) y falla la compilación si no se siguen los estándares?
Esas comprobaciones continuas de integración deben ser muy, muy rápidas. Cualquier retraso significativo significará que sus programadores se comprometerán y perderán la noción de su proceso de pensamiento mientras esperan los resultados. Hazlo más largo y se comprometerán y tomarán una taza de café o conversarán con sus compañeros de oficina sobre el último rendimiento de algunos equipos deportivos. Esos retrasos son altamente contraproducentes. Es mejor dejar algunas cosas para la compilación nocturna o la revisión del código.
¿Qué tipos de reglas no deben usarse para fallar la compilación?
Los subjetivos, para empezar. ¿Cómo hace cumplir la regla de "El código debe ser autodocumentado o bien comentado"? ¿La regla de "no hay números mágicos"? Esas son las cosas que mejor se dejan a la revisión del código.
Otra categoría son las violaciones a las reglas a las que ya se les ha otorgado una exención. Dada una base de código considerable, inevitablemente habrá un trozo de código donde violar el estándar es exactamente lo que hay que hacer.
Como parte de un Plan de mejora de la calidad del software, recientemente codificamos una serie de análisis de código para integrarlos en nuestro proceso de compilación.
Construimos mucho, al ser una aplicación PHP no existe una compilación real, por lo que la compilación es realmente una prueba unitaria / análisis estático / corredor, y podemos permitirnos pasar unos pocos ciclos en esto.
Tuvimos algunos problemas de calidad del código y algunos códigos heredados con muchos problemas.
Comenzando sobre la base de que si no falla la confirmación, se ignorará, comenzamos a confirmar las confirmaciones contra nuestro estándar de codificación 'deseado', y las confirmaciones fallidas con errores que no cumplieron con el estándar.
El mantenimiento se detuvo, incluso la solución más simple a un componente heredado requirió que el desarrollador reformatee grandes cantidades de fuente, y la construcción se rompió con mayor frecuencia que no. No hace falta decir que cambiamos los errores a advertencias, y ahora son ignorados y 'sobre todo' inútiles.
Entonces diría esto (aprendido de la experiencia difícil).
Asegúrese de que el estándar de su base de código esté lo suficientemente cerca del estándar que imponga para que no requiera que los desarrolladores vuelvan a formatear volúmenes de código, instantáneamente. O ... Estás preparado y esperando el aumento de esfuerzo.
Al ser un equipo pequeño con un gran requisito de entrega, no podíamos permitirnos cambiar el equipo a una gran operación de refactorización. Nuestros estándares de codificación ahora se manejan principalmente mediante revisión manual, y el legado se está reescribiendo como parte de un plan de mejora continua.
Cuando dije que las advertencias son "en su mayoría" inútiles, ahora las usamos para registrar estadísticas que nos permiten medir los kpi que deberían seguir mostrando una mejora.
Cuando volvamos a aplicar el código olfativo, comenzaremos de forma ligera e introduciremos algunos olores a la vez hasta que apliquemos el estándar.
Dependerá de su objetivo y estrategia final .
Forzar todos los buenos estándares mencionados en el servidor CI puede parecer muy lucrativo. Sin embargo, podría no ser práctico para el gran equipo de desarrollo (más de 6 desarrolladores), si se realiza en cada confirmación con el servidor. Esperar a que su servidor responda después de la confirmación NO debe demorar mucho. Potencialmente puede causar algún tiempo de inactividad.
Sin embargo, es totalmente legítimo bloquear una confirmación si el código (el conjunto de cambios real) tiene problemas de dependencia o no se compila. Sin embargo, el código defectuoso debido al diseño del código y algunas convenciones de nomenclatura pueden ser demasiado severas y no una restricción vital para las reglas de confirmación del servidor CI.
Pero es muy probable que sea una regla útil si se aplica durante la construcción nocturna.
Además, las herramientas de refactorización pueden ayudar a implementar y aprender estándares, como Resharper o JustCode uso de por parte de los desarrolladores.