10 consejos para la limpieza del análisis estático

¿Quiere limpiar su práctica de análisis estático? Empiece por despejar el desorden que dificulta concentrarse en los problemas que realmente le interesan. A continuación, fortalezca su iniciativa ampliando su alcance de manera que aumente su valor para su organización.

¿Su equipo de desarrollo está abrumado por la creciente cantidad de violaciones de su herramienta de análisis estático? ¿El alto nivel de ruido generado por su configuración actual de análisis estático ha desensibilizado al equipo a todas las alertas, incluidas las relacionadas con problemas que considera críticos?

Aquí hay 10 formas de actualizar su implementación de análisis estático existente, sin importar qué herramienta de análisis estático estás usando.

Sugerencia 1: Deshabilite las reglas de análisis estático para las infracciones que no está comprometido a corregir en este momento

Verificar muchas reglas no es el secreto para lograr el mejor ROI con análisis estático. De hecho, en muchos casos ocurre lo contrario. El análisis estático en realidad ofrece mejores resultados si se enfoca en un conjunto de reglas mínimo pero significativo.

Cuando realiza un análisis estático, es como si tuviera un desarrollador experimentado que se colocara sobre el hombro de un desarrollador sin experiencia y le diera consejos mientras escribe código. Si el desarrollador experimentado está constantemente insistiendo en los problemas delicados en cada pocas líneas de código, el desarrollador menos experimentado pronto se sentirá abrumado y comenzará a filtrar todos los consejos, tanto buenos como malos. Sin embargo, si el desarrollador experimentado se centra en uno o dos problemas que sabe que pueden causar problemas graves, es mucho más probable que el desarrollador menos experimentado recuerde los consejos que se le dieron, comience a escribir un código mejor y realmente aprecie recibir este tipo de comentarios. .

Lo mismo ocurre con el análisis estático. Si lo mantiene manejable y significativo, terminará enseñando más a sus desarrolladores y haciendo que se resientan mucho menos con el proceso. ¿Preferiría tener un conjunto pequeño de reglas que se sigan o un conjunto grande que no? Si realmente no espera que los desarrolladores eliminen las violaciones de una regla tan pronto como se informen, es posible que desee considerar seriamente la desactivación de esa regla.

Sugerencia 2: Deshabilite las reglas de análisis estático que causan demasiado ruido

Si una regla en particular se viola repetidamente, ahora es una buena oportunidad para reevaluar si realmente desea continuar verificando esa regla. Un número excesivo de infracciones indica que los desarrolladores no están escribiendo código de la forma que exige la regla. Convencerlos de que cambien sus hábitos de codificación podría encontrar bastante resistencia.

¿Cómo se puede determinar si valdrá la pena el esfuerzo de presionar el tema? Primero, trate de recordar por qué comenzó a buscar ese problema en primer lugar. ¿Lo seleccionó porque le pareció una buena manera de abordar los problemas que está experimentando en el campo? ¿Como parte de sus esfuerzos de cumplimiento normativo? ¿O simplemente porque el proveedor lo habilitó de forma predeterminada? Los proveedores suelen proporcionar la referencia para cada regla en sus descripciones de reglas. La lectura de estas descripciones puede ayudarlo a determinar si la regla es realmente una buena opción para sus proyectos y objetivos.

A continuación, vea si hay una forma alternativa de lograr el resultado deseado. ¿Existe una regla alternativa que sea más específica? ¿Hay alguna forma de ajustar los parámetros de la regla para que no se active con tanta frecuencia? (Más sobre esto en el consejo n. ° 6). Incluso podría considerar escribir su propia regla que se ajuste mejor, o hacer que el proveedor cree una regla personalizada para usted.

Si aún está interesado en verificar esta regla después de volver a examinar sus beneficios y explorar sus alternativas, obtenga algunos comentarios de desarrollo sobre lo que implicaría seguir esta regla. Luego, puede usar estos comentarios para determinar si realmente vale la pena exigir a los desarrolladores que sigan esta regla. Si parece mucho trabajo por poco beneficio, continúe y desactive la regla.

Sugerencia 3: Utilice supresiones para permitir infracciones en situaciones específicas

En algunos casos, es posible que esté comprometido a seguir una regla, pero desee permitir exenciones en determinadas circunstancias. Por ejemplo, tal vez tenga una regla que requiera que se realice algún nivel adicional de validación en el código. Suponga que tiene un método determinado con código crítico para el rendimiento que se llama cientos de veces por minuto, y ya ha verificado que se realiza un nivel adecuado de validación antes de llamar a este método en particular. O bien, suponga que el análisis basado en flujo le advierte sobre un problema grave en una ruta que está 100% seguro de que no se puede seguir en la aplicación integrada. Aquí es donde las supresiones resultan útiles.

Las supresiones son ideales para situaciones en las que desea verificar algo, pero no le importan los problemas reportados en situaciones excepcionales. Con las supresiones, puede continuar verificando un problema crítico sin recibir mensajes repetidos sobre sus violaciones intencionales de las reglas. Si no desea recibir mensajes de error por cualquier infracción de una regla específica, le recomendamos que desactive la regla por completo (consulte el punto 1).

Por lo general, puede definir supresiones desde la GUI de la herramienta de análisis estático, un archivo de configuración o el código fuente en sí. Cuando las supresiones se definen en el código fuente:

• Se asegura de que se apliquen las mismas supresiones siempre que usted o un miembro del equipo analicen ese código.
• Puede agregar comentarios de código que expliquen cada supresión para que el motivo de cada supresión sea siempre claro cuando usted o los miembros del equipo estén revisando o modificando el código.
• Obtiene un control detallado sobre qué reglas se aplican a nivel de archivo, clase o línea.

Por lo general, puede suprimir las infracciones de una regla específica, varias reglas o todas las infracciones de una categoría específica. También puede eximir ciertas secciones de código de todo análisis estático (más sobre esto en el siguiente punto).

Sugerencia 4: Deje de analizar archivos problemáticos o fragmentos de código

A veces simplemente no tiene sentido ejecutar un análisis estático en ciertos archivos, por ejemplo, archivos generados automáticamente o archivos heredados que no planea tocar. En estos casos, debe evitar que se analicen estos archivos. Esta es otra forma de asegurarse de que sus resultados no estén abarrotados de infracciones que no planea corregir.
Hay varias formas de hacer esto. Puede configurar filtros de ruta para excluir los archivos que no desea verificar o incluir solo los que sí desea verificar. O bien, puede configurar su herramienta para omitir archivos que contengan un comentario determinado, como un comentario que indique un código generado automáticamente.

Otras formas de enfocar su cuenta de cheques incluyen:

• Agregar marcadores para indicar bloques específicos de código que desea verificar dentro de archivos que de otro modo estarían exentos.
• Excluir ciertos métodos dentro de archivos que de otro modo se analizarían.
• Comprobando solo los archivos que no se agregaron o modificaron desde una fecha límite determinada.
• Comprobando solo los archivos que se agregaron o modificaron después de una "fecha límite" o dentro de un cierto número de días.

Sugerencia 5: Notifique al proveedor de la herramienta de análisis estático sobre reglas rotas que causen falsos positivos

Con el análisis estático basado en patrones, los falsos positivos son violaciones de reglas que se informan erróneamente cuando el código realmente sigue la regla. Por ejemplo, si la regla dice que tiene un recurso no cerrado (como una conexión JDBC), cuando en realidad la conexión está cerrada, esto es un falso positivo. Si encuentra un problema como este en una regla que realmente desea seguir, la limpieza de primavera es un buen momento para informarlo finalmente a su proveedor.

Tenga en cuenta que si va por este camino, debe estar seguro de que está viendo un falso positivo real, en lugar de simplemente una regla que no le gusta. Los desarrolladores suelen llamar a un mensaje un "falso positivo" porque no les gusta la regla, o no sienten que se aplique en este caso. Dichos mensajes no son falsos positivos y su proveedor no podrá ayudarlo en estos casos.

Sin embargo, si puede reducir un caso de prueba simple que muestra cómo una regla en particular está recibiendo un mensaje falso, debería encontrar que la mayoría de los proveedores son muy útiles para solucionar el problema.

Sugerencia 6: Personalice los parámetros de las reglas de análisis estático para satisfacer sus necesidades

Otra forma de reducir el factor de ruido es personalizar los parámetros de las reglas. Por ejemplo, suponga que su equipo está desarrollando Android y está comprobando una regla de Android que dice "Asegúrese de que los widgets no se actualicen con demasiada frecuencia".

Con la configuración predeterminada, esta regla identifica el código que configura un widget para que se actualice más de 4 veces al día. Lo hace marcando el código que establece el elemento [android: updatePeriodMillis] en la etiqueta [appwidget-provider] en un número menor que 216,00,000.

Suponga que obtener información actualizada es fundamental para su aplicación, por lo que está dispuesto a sacrificar parte del consumo de batería por actualizaciones más frecuentes. En este caso, es posible que desee recibir una advertencia solo si las actualizaciones se realizan más de 8 veces al día. Para lograr esto, simplemente puede actualizar el parámetro de la regla “Tiempo máximo de actualización máximo en milisegundos” de 21,600,000 ms (6 horas) a 10,800,000 ms (3 horas).

Como se menciona en el consejo n. ° 2, si la regla no tiene los parámetros que necesita, puede escribir uno nuevo que sí los tenga, o hacer que su proveedor (o un consultor) escriba una regla personalizada para usted.

Sugerencia 7: Asigne reglas de análisis estático a sus propios términos

¿Está cansado de recordar que Security 123 es equivalente a su directriz ACME 3.1? ¿Que tanto Performance 987 como Performance 567 están relacionados con su directriz ACME 5.6? ¿Que a pesar de que su herramienta dice que Threads 123 es de gravedad 4, su organización considera que las violaciones de esa regla son un defecto muy severo?

Si es así, la limpieza de primavera es un buen momento para mapear el conjunto de reglas de análisis estático de su proveedor para que coincida con las distintas políticas definidas por su equipo y / u organización. La mayoría de las herramientas de análisis estático le permiten personalizar la gravedad de las reglas, los ID y los nombres, así como crear nuevas categorías de reglas, para que las reglas implementadas coincidan con precisión con el contenido de su propio documento de política de codificación.

Si su organización realiza un análisis estático como parte de un esfuerzo de cumplimiento, esto hará que sus informes sean mucho más fáciles.

Sugerencia 8: Vuelva a examinar y aclare su política de análisis estático

Cada equipo tiene una política, esté o no definida formalmente. También puede codificar el proceso y hacerlo oficial. Después de todo, es mucho más fácil identificar y diagnosticar problemas con una política formalizada que con una no escrita.

Idealmente, desea que su póliza tenga una correlación directa con los problemas que está experimentando actualmente (y / o comprometido a prevenir). De esta manera, hay una buena razón detrás tanto de la política general como de las formas específicas en que se implementa.

Con estos objetivos en mente, la política debe aclarar:

• Qué necesitan los equipos para realizar análisis estáticos
• Qué proyectos requieren análisis estático
• Que reglas se requieren
• Qué grado de cumplimiento se requiere
• Cuando se permiten las supresiones
• Cuando es necesario corregir las infracciones en el código heredado
• Si envía código con infracciones de análisis estático

Sugerencia 9: Incrementar el alcance del análisis

Una vez que haya limpiado el desorden y esté en el punto en el que el equipo está acostumbrado a realizar análisis estáticos, se informan pocos problemas y esos problemas informados se limpian rápidamente, puede dar el siguiente paso y expandir el alcance de la comprobación.

Una forma de expandir el alcance de la verificación es agregar más reglas que son críticas para sus proyectos y objetivos. Para concentrarse en qué reglas agregar, considere:

• ¿Qué reglas parece probable que eviten los problemas informados sobre el terreno que consumen gran parte de los recursos de su equipo?
• Si pronto necesitará comenzar a cumplir con iniciativas de cumplimiento organizacional o específicas de la industria, ¿qué reglas lo ayudarían a impulsar sus esfuerzos?
• Cuando creó por primera vez o optimizó por última vez su conjunto de reglas, ¿qué reglas era más reacio a recortar?

Otra forma de aumentar el alcance de la verificación es verificar código adicional. Si inicialmente configuró su herramienta de análisis estático para omitir archivos heredados (por ejemplo, omitir los archivos que no se agregaron o modificaron después de la fecha de "corte" cuando comenzó el análisis estático), es posible que desee considerar retroceder esa fecha de corte o eliminar todo junto.

Sugerencia 10: Automatizar, automatizar, automatizar

Cuanto más pueda automatizar el proceso de análisis estático, menos será una carga para los desarrolladores y los distraerá de las tareas más desafiantes que realmente disfrutan. Además, la automatización adicional lo ayudará a lograr resultados consistentes en todo el equipo y la organización.

Muchas organizaciones siguen un proceso automatizado de varios niveles. Cada día, a medida que el desarrollador trabaja en el código en el IDE, puede ejecutar análisis a pedido o configurar un análisis automatizado para que se ejecute continuamente en segundo plano (como lo hace el corrector ortográfico). Los desarrolladores limpian estas infracciones antes de agregar código nuevo o modificado al control de código fuente.

Luego, un proceso basado en servidor verifica dos veces que el código base verificado esté limpio. Este análisis se puede ejecutar como parte de una integración continua, todas las noches, etc. para asegurarse de que nada se escape. Con un proceso basado en servidor de este tipo, es importante evitar el antiguo paradigma de enviar correo electrónico a los desarrolladores. Parte de un flujo de trabajo eficaz consiste en distribuir los mensajes de error a la misma interfaz de usuario donde el desarrollador escribe el código. El correo electrónico obliga a pasos adicionales, lo que lleva a infracciones omitidas, pérdida de tiempo para encontrar la línea adecuada en el archivo y más resentimiento por parte de los codificadores que sienten que están haciendo algo más fuera de su proceso habitual.

Para optimizar aún más el flujo de trabajo a través de la automatización, considere:

• Enrutar automáticamente cada problema informado directamente al desarrollador responsable, así como personalizar la priorización de problemas para que se adapte a las prioridades de su política, para garantizar que sus problemas más críticos se aborden de manera oportuna.
• Centralización de la gestión de la configuración para garantizar que los conjuntos de reglas se apliquen de forma coherente y se puedan actualizar sin esfuerzo a medida que evolucionan las prioridades y los procesos.
• Aprovechar la refactorización automatizada de "solución rápida" siempre que sea posible para ayudar al equipo a corregir las infracciones de las reglas lo más rápido posible.