si enciendo las advertencias y avisos en estos sitios web de producción en vivo, se sobrecargarán con ellos.
Siempre debe tener las advertencias activadas al máximo nivel en desarrollo, pruebas y control de calidad, pero no en producción. En realidad, si se trata de una aplicación de alimentación para perros, es decir, una aplicación que usted usa, entonces también debe activarlas en producción.
Básicamente: actívelos en aquellos casos en que la persona que los ve esté en condiciones de hacer algo al respecto (el desarrollador en desarrollo y prueba puede solucionarlos él mismo, el probador en QA puede presentar un error, y si el desarrollador está también el usuario, entonces también puede arreglarlo en producción), pero no los encienda cuando la persona que ve no puede hacer nada al respecto (un usuario en producción, que ni siquiera sabe programar).
Idealmente, también querrás activar el tratamiento de las advertencias como errores, pero eso solo funciona si no hay ninguno para empezar ;-) ¡Pero ten esto en cuenta como un objetivo! Si es posible activar / desactivar esta función por archivo, actívela para todos los archivos nuevos, y actívela para todos los archivos sin advertencia, y nunca la apague nuevamente una vez activada.
Entonces, ¿qué hacer con la sobrecarga?
Usted hace una lista de todas las advertencias y avisos, y luego se adhiere a las siguientes reglas:
- Nunca, nunca, bajo ninguna circunstancia agregue una nueva advertencia a la lista. Cada nueva pieza de código, cada edición, cada cambio, cada parche, cada confirmación no debe introducir nuevas advertencias, solo puede corregirlas .
- Cada vez que toque un fragmento de código, repare todas y cada una de las advertencias en ese fragmento de código. (La regla Boyscout: siempre deje el campamento en mejores condiciones de lo que lo encontró). De esa manera, el código no importante puede estar lleno de advertencias, pero el código importante se volverá más limpio con el tiempo. El "fragmento de código" puede ser una función, una clase, un archivo. También puede relajar esta regla para decir que arregle al menos una advertencia. El punto es: arreglarlos a medida que los encuentre.
Nota: ambos requieren que tenga algún tipo de base de datos de registro y mecanismo de filtrado de registro. Tenga en cuenta también que la "base de datos de registro" y el "mecanismo de filtrado de registro" podrían ser simplemente un archivo de texto y grep.
Esta es la parte importante. Sin la base de datos, no sabrá cuándo agrega una nueva advertencia, y sin el filtrado, todavía tiene el problema de sobrecarga.
Nota n. ° 2: esto no solo funciona para advertencias, también funciona para verificadores de estilo, métricas de complejidad, cobertura de código, herramientas de análisis estático, etc. Básicamente:
- No agregues nuevos problemas.
- Solucione viejos problemas a medida que los encuentre.
Esto le permite priorizar fácilmente: el código que se edita con frecuencia y, por lo tanto, debe ser fácil de leer y mantener, mejorará con el tiempo. El código que no se toca con frecuencia, no mejorará, pero está bien, porque nadie necesita verlo de todos modos. Y , al menos, no empeorará.
Por supuesto, nada le impide asignar tiempo específicamente para no hacer nada más que cazar y matar advertencias. Es solo que a menudo, esto no es económicamente viable, y es su trabajo como ingeniero tener eso en cuenta. "Un ingeniero es aquel que puede construir con un dólar, lo que cualquier tonto puede construir con dos".
@.