Trabajar con objeciones: el análisis estático tomará parte del tiempo de trabajo

Al comunicarnos con personas en conferencias y en comentarios a artículos, nos encontramos con la siguiente objeción: el análisis estático reduce el tiempo dedicado a la búsqueda de errores, pero toma tiempo de los programadores, lo que elimina el beneficio de su uso e incluso ralentiza el proceso de desarrollo. Analicemos esta objeción y demostremos que no tiene fundamento.

La afirmación "el análisis estático ocupará parte del tiempo de trabajo" aislada del contexto es cierta. La revisión periódica de las advertencias del analizador estático emitidas para el código nuevo o modificado realmente lleva tiempo. Sin embargo, el pensamiento debe continuar: pero el tiempo dedicado a esto es mucho menor que el dedicado a identificar errores por otros métodos. Aún peor es aprender sobre los errores de los clientes.

Aquí, las pruebas unitarias pueden ser una muy buena analogía. Las pruebas unitarias también toman tiempo para los desarrolladores, pero esta no es una razón para no usarlas. El beneficio de escribir un código mejor y más confiable cuando se usan pruebas unitarias excede 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 verse como una primera aproximación como una extensión de las advertencias del compilador. Naturalmente, cuando un programador ve una advertencia del compilador, pasa tiempo en ella. Debería cambiar el código o pasar tiempo explícitamente suprimiendo la advertencia, por ejemplo, usando #pragma. Sin embargo, esta vez no es una razón para deshabilitar las advertencias del compilador. Y si alguien hace esto, otros lo interpretarán inequívocamente como inadecuación profesional.

Sin embargo, ¿de dónde viene el temor a la necesidad de pasar tiempo advirtiendo a los analizadores de código estático?

Todo es muy sencillo. Los programadores que todavía son nuevos en esta metodología confunden las ejecuciones de prueba y el uso regular. En los primeros inicios, 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. Un analizador sintonizado genera una pequeña cantidad de falsos positivos durante los lanzamientos regulares. En otras palabras, la mayoría de las advertencias revelan defectos reales o un código de olor. Solo es importante hacer esta configuración. Este es todo el truco que convierte un analizador estático del mal, que lleva tiempo, en un amigo y un ayudante.

Cualquier analizador estático producirá primero muchos falsos positivos. Hay muchas razones para esto, y este tema merece un artículo separado. Naturalmente, tanto nosotros como los desarrolladores de otros analizadores luchamos con falsos positivos. Pero aún habrá muchos aspectos positivos si, sin preparación, de repente toma y ejecuta el analizador en algún proyecto. La misma imagen, por cierto, con advertencias del compilador. Supongamos que tiene un proyecto grande que siempre ha creado, por ejemplo, utilizando el compilador de Visual C ++. Supongamos que el proyecto fue milagrosamente portátil y compilado usando GCC. Aun así, recibirá una montaña de advertencias del CCG. Cualquiera que haya experimentado un cambio de compiladores en un proyecto grande comprende de qué se trata.

Sin embargo, nadie obliga a cavar constantemente en las montañas de basura de las advertencias después de cambiar el compilador o después de iniciar el analizador. El siguiente paso natural es configurar el compilador o el analizador. Quienes dicen que "el análisis de advertencias lleva mucho tiempo" evalúa la complejidad de implementar la herramienta, pensando solo en todas estas advertencias que deben superarse al principio, pero no piensan en un uso regular y tranquilo.

Configurar analizadores, así como compiladores, no es tan complicado y laborioso como a los programadores les gusta asustar. Si es gerente, no los escuche. Son simplemente vagos. El programador puede decir con orgullo cómo pasó 3 días buscando el error encontrado por el probador / cliente. Y esto es normal para él. Sin embargo, desde su punto de vista, es inaceptable pasar un día ajustando la herramienta, después de lo cual se detectará un error similar antes de que entre al sistema de control de versiones.

Sí, habrá falsas alarmas después de la sintonización. Pero su número es exagerado. Es muy posible configurar el analizador de modo 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, que se puede encontrar con más detalle en este artículo .

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

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

Y esto no es un problema, sino un intento de encontrar una razón para no introducir algo nuevo. Por supuesto, no todo es fácil en un proyecto grande. Pero, en primer lugar, brindamos soporte y ayudamos a integrar PVS-Studio en el proceso de desarrollo. Y en segundo lugar, no es necesario comenzar a resolver todas las advertencias.

Dado que su aplicación funciona, significa que los errores allí no son tan críticos y probablemente se encuentren en un código poco utilizado. Ya se han encontrado y corregido errores evidentes con métodos más lentos y costosos. Pero al respecto a continuación en una nota . Ahora algo más es importante para nosotros. No tiene sentido realizar ediciones masivas en el código, corrigiendo muchos errores menores. Con tanta refactorización, algo es fácil de romper y habrá más daño que bien.

Es mejor considerar las advertencias existentes como una deuda técnica. Será posible volver a endeudarse más tarde y trabajar con viejas advertencias gradualmente. Usando el mecanismo de supresión de alertas masivas , puede comenzar a usar rápidamente PVS-Studio en un proyecto grande. Muy brevemente, sucede así:

1. Excluye directorios explícitamente redundantes (bibliotecas de terceros) del análisis. En cualquier caso, esta configuración se realiza mejor desde el principio para reducir el tiempo de análisis.
2. Intenta PVS-Studio y estudia las advertencias más interesantes . Le gustan los resultados y muestra la herramienta a colegas y superiores. El equipo decide comenzar su uso regular.
3. El proyecto está siendo verificado. Todas las advertencias encontradas se desactivan utilizando el mecanismo de supresión masiva. En otras palabras, todas las advertencias disponibles actualmente se consideran una deuda técnica, que se puede devolver más tarde.
4. El archivo resultante con advertencias suprimidas se establece en el sistema de control de versiones. Este archivo es grande, pero no da miedo. Realiza esta operación una vez (o, al menos, lo hará extremadamente raramente). Y ahora este archivo aparecerá en todos los desarrolladores.
5. Ahora todos los desarrolladores ven advertencias que se aplican solo a código nuevo o modificado. A partir de este momento, el equipo comienza a beneficiarse del análisis estático. Configure gradualmente el analizador y haga deuda técnica.

Por cierto, el sistema para almacenar advertencias poco interesantes es lo suficientemente inteligente. Los hashes se almacenan para una cadena con un posible error, así como para el anterior y el siguiente. Debido a esto, si se agrega una línea al comienzo de uno de los archivos, entonces nada se "corroerá" y el analizador seguirá en silencio sobre el código considerado un deber técnico.

Espero que hayamos podido disipar uno de los prejuicios con respecto al 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 en general sea más confiable y de alta calidad.

Nota

Al desarrollar cualquier proyecto, constantemente aparecen nuevos errores y se corrigen. Los errores no detectados "se asientan" en el código durante mucho tiempo, y luego se pueden detectar muchos de ellos al ejecutar el análisis de código estático. Debido a esto, a veces existe la falsa sensación de que los analizadores estáticos encuentran solo algunos errores poco interesantes en secciones de código poco utilizadas. Por supuesto, este es el caso si usa el analizador incorrectamente y lo ejecuta solo de vez en cuando, por ejemplo, poco antes del lanzamiento de la versión. Más sobre este tema aquí . Sí, al escribir artículos, nosotros mismos realizamos verificaciones únicas de proyectos abiertos. Pero tenemos un objetivo diferente. Queremos demostrar las capacidades de un analizador de código para detectar defectos. Esta tarea tiene poco que ver con mejorar la calidad del código del proyecto en su conjunto y reducir los costos asociados con la corrección de errores.

Enlaces adicionales:

1. PVS-Studio ROI .
2. El análisis estático mejorará la base de código de proyectos complejos de C ++ .
3. Heisenbug 2019. Informe de Ivan Ponomarev " Análisis continuo de código estático ".
4. Ivan Ponomarev. Incruste el análisis estático en el proceso, no busque errores con él .

Si desea compartir este artículo con una audiencia de habla inglesa, utilice el enlace a la traducción: Andrey Karpov. Manejo de objeciones: el análisis estático ocupará parte del tiempo de trabajo .