Manejo de objeciones: el análisis estático ocupará parte del tiempo de trabajo

Hablando con personas en conferencias y en comentarios a artículos, nos enfrentamos a la siguiente objeción: el análisis estático reduce el tiempo para detectar errores, pero toma el tiempo de los programadores, lo que niega los beneficios de usarlo e incluso ralentiza el proceso de desarrollo. Aclaremos esta objeción e intentemos demostrar que no tiene fundamento.

La afirmación "el análisis estático le quitará parte del tiempo de trabajo" fuera del contexto es correcta. Definitivamente lleva algún tiempo revisar regularmente las advertencias del analizador, emitidas para código nuevo o modificado. Sin embargo, debemos continuar con la idea: pero el tiempo dedicado a esto es mucho menor que el tiempo necesario para encontrar errores por otros métodos. Es aún peor descubrir errores de los usuarios.

Las pruebas unitarias pueden ser una muy buena analogía aquí. Las pruebas unitarias también toman tiempo de los desarrolladores, pero no es la razón para no usarlas. Los beneficios de un código más seguro y de mejor calidad cuando se utilizan pruebas unitarias superan el costo de escribirlos.

Otra analogía: advertencias del compilador. Este es generalmente un tema muy cercano, ya que las advertencias de las herramientas de análisis estático pueden considerarse como una extensión de las advertencias del compilador hasta cierto punto. Naturalmente, cuando un programador ve una advertencia del compilador, pasa algún tiempo lidiando con ella. Tiene que cambiar el código o claramente pasar algún tiempo suprimiendo advertencias, por ejemplo, usando #pragma. Sin embargo, este compromiso de tiempo nunca ha sido la razón para deshabilitar las advertencias del compilador. Y si alguien hace eso, los demás lo interpretarán inequívocamente como incapacidad profesional.

Sin embargo, ¿de dónde viene el miedo a perder el tiempo por las advertencias de los analizadores de código estático?

La respuesta es muy simple. Los programadores que aún no están familiarizados con esta metodología confunden los lanzamientos de prueba y el uso regular. En la primera ejecución, cualquier analizador ofrece una gran lista de advertencias, lo que es incluso aterrador de ver. La razón es que el analizador aún no está configurado. Mientras que un analizador configurado emite una pequeña cantidad de falsos positivos que se utilizan regularmente. En otras palabras, la mayoría de las advertencias indican defectos reales u olores de código. Es importante hacer esta configuración. Este es el truco que convierte un analizador estático de un mal desperdiciador de tiempo en un amigo y un asistente.

Cualquier analizador estático emitirá primero muchos falsos positivos. Hay muchas razones para esto, y este tema merece un artículo separado. Naturalmente, tanto los desarrolladores de otros analizadores como nuestro equipo luchan contra los falsos positivos. Pero aún habrá muchas advertencias, si solo toma y ejecuta el analizador en un proyecto por primera vez. Por cierto, la misma situación es con las advertencias del compilador. Supongamos que tiene un gran proyecto que siempre ha estado construyendo, por ejemplo, con el compilador de Visual C ++. Digamos que el proyecto milagrosamente resultó ser portátil y compilado usando GCC. Aun así, recibirá un montón de advertencias de GCC. Las personas que han experimentado un cambio de compiladores en un gran proyecto entienden de lo que estoy hablando.

Sin embargo, nadie lo obliga a excavar constantemente las pilas de advertencias después de cambiar el compilador o después de ejecutar el analizador. El siguiente paso obvio es configurar un compilador o analizador. Quienes dicen que "el análisis de advertencias lleva mucho tiempo" evalúan la complejidad de adoptar la herramienta, pensando solo en todas estas advertencias que deben superarse al principio, pero no piensen en el uso regular sin prisas.

Configurar analizadores, así como compiladores, no es tan difícil y laborioso como a los programadores les gusta progresar. Si eres gerente, no los escuches. Solo están siendo flojos. El programador puede decir con orgullo cómo estaba buscando un error encontrado por el probador / cliente durante 3 días. Y eso está bien para él. Sin embargo, desde su punto de vista, no es aceptable pasar un día configurando la herramienta, después de lo cual se detectará dicho error antes de que ingrese al sistema de control de versiones.

Sí, los falsos positivos estarán presentes después de la configuración. Pero su número es exagerado. Es muy posible configurar un analizador para que el porcentaje de falsos positivos sea del 10% al 15%. Es decir, para 9 defectos encontrados, solo 1 advertencia requerirá supresión como falsa. Entonces, ¿dónde está la "pérdida de tiempo" aquí? Al mismo tiempo, el 15% es un valor muy real; Puedes leer más sobre esto en este artículo .

Queda una cosa más. Un programador puede objetar:

Bueno, digamos que las ejecuciones regulares de análisis estático son realmente efectivas. ¿Pero qué hacer con el ruido que recibo la primera vez? En nuestro gran proyecto, no podremos configurar la herramienta para 1 día prometido. Solo la recompilación para verificar el próximo lote de configuraciones lleva varias horas. No estamos listos para pasar un par de semanas en esto.

Y esto no es un problema, sino un intento de encontrar una razón para no introducir algo nuevo. Por supuesto, en un gran proyecto, todo siempre es difícil. Pero primero, brindamos soporte y ayudamos a integrar PVS-Studio en el proceso de desarrollo. Y en segundo lugar, no es necesario comenzar inmediatamente a clasificar todas las advertencias.

Si su aplicación funciona, entonces los errores que existen allí, no son tan críticos y probablemente viven en un código poco utilizado. Ya se han encontrado y solucionado errores obvios serios utilizando métodos más lentos y caros. Escribiré sobre esto a continuación en la nota . Eso no es lo que es de gran importancia ahora. No tiene sentido realizar ediciones masivas en el código, corrigiendo muchos errores insignificantes. Con una refactorización tan grande, es fácil romper algo y el daño será más que bueno.

Es mejor tener en cuenta las advertencias existentes de la deuda técnica. Puede volver a la deuda más tarde y trabajar gradualmente con las viejas advertencias. Al usar el mecanismo de supresión de advertencias masivas, puede comenzar a usar PVS-Studio rápidamente en un proyecto grande. Aquí hay una breve descripción de lo que está sucediendo:

1. Excluye directorios obviamente redundantes (bibliotecas de terceros) del análisis. Será mejor que lo haga desde el principio para reducir el tiempo de análisis.
2. Intenta PVS-Studio e investiga las advertencias más interesantes . Te gustan los resultados y muestras la herramienta a colegas y jefes. El equipo decide comenzar a usarlo regularmente.
3. El proyecto está siendo revisado. Todas las advertencias suprimidas se desactivan mediante el mecanismo de supresión masiva. En otras palabras, todas las advertencias que tiene en este momento ahora se consideran una deuda técnica que se puede revisar más adelante.
4. El archivo resultante con advertencias suprimidas ingresa al sistema de control de versiones. Este archivo es grande, pero está bien. Realiza estas acciones solo una vez (o, al menos, muy raramente). Y ahora todos los desarrolladores tendrán este archivo.
5. Ahora todos los desarrolladores ven advertencias que solo están relacionadas con código nuevo o modificado. A partir de ese momento, el equipo comienza a beneficiarse del análisis estático. Luego, configura gradualmente el analizador y se ocupa de la deuda técnica.

Por cierto, el sistema de almacenamiento de advertencias poco interesantes es bastante inteligente. Los hashes se guardan para la línea con un posible error, así como para la línea anterior y la siguiente. Como resultado, si agrega una línea al comienzo de uno de los archivos, nada se perderá y el analizador guardará silencio para el código, que se considera una deuda técnica.

Espero haber logrado disipar una de las ideas preconcebidas sobre el análisis estático. Ven, descarga y prueba nuestro analizador de código estático PVS-Studio. Detectará muchos errores en las primeras etapas y hará que su código sea generalmente más confiable y mejor.

Nota

Al desarrollar cualquier proyecto, constantemente aparecen nuevos errores y se solucionan. Los errores no encontrados "se asientan" en el código durante mucho tiempo, y luego se pueden detectar muchos de ellos cuando se aplica el análisis de código estático. Esto a veces da la falsa impresión de que los analizadores estáticos encuentran solo algunos errores poco interesantes en piezas de código poco utilizadas. Bueno, es cierto, en caso de que use el analizador incorrectamente y lo ejecute solo de vez en cuando, por ejemplo, poco antes del lanzamiento. Más sobre este tema está escrito aquí . Sí, nosotros mismos hacemos verificaciones únicas de proyectos de código abierto cuando escribimos artículos. Pero tenemos un propósito diferente. Nos centramos en demostrar las capacidades del analizador de código para detectar defectos. En términos generales, esta tarea tiene poco que ver con mejorar la calidad del código del proyecto y reducir el costo de corregir errores.

Enlaces Adicionales

1. PVS-Studio ROI .
2. Por qué el análisis estático puede mejorar una base de código compleja de C ++ .
3. Ivan Ponomarev. Introduzca el análisis estático en el proceso, no solo busque errores con él .