¿Qué es el análisis estático?
¿Qué es el análisis estático?
El análisis estático es el análisis automatizado del código fuente sin ejecutar la aplicación.
Cuando el análisis se realiza durante la ejecución del programa, se conoce como Análisis Dinámico.
El análisis estático se utiliza a menudo para detectar:
- Vulnerabilidades de seguridad.
- Problemas de rendimiento.
- Incumplimiento de las normas.
- Uso de construcciones de programación obsoletas.
¿Cómo funciona una herramienta de análisis estático?
El concepto básico común a todas las herramientas de análisis estático es buscar en el código fuente para identificar patrones de codificación específicos que tengan algún tipo de advertencia o información asociada.
Esto podría ser tan simple como "Las clases de prueba de JUnit 5 no necesitan ser 'públicas'". O algo complejo de identificar como "Se está utilizando una entrada de cadena no fiable en una sentencia de ejecución SQL".
Las herramientas de análisis estático varían en la forma de implementar esta funcionalidad.
- tecnología de análisis de código fuente para crear un árbol de sintaxis abstracta (AST),
- texto Coincidencia de expresiones regulares,
- una combinación de las anteriores.
La concordancia de expresiones regulares en el texto es muy flexible, fácil de escribir reglas de concordancia, pero a menudo puede conducir a una gran cantidad de falsos positivos y las reglas de concordancia ignoran el contexto del código circundante.
La concordancia AST trata el código fuente como código de programa, y no sólo como archivos llenos de texto, lo que permite una concordancia más específica y contextual y puede reducir el número de falsos positivos reportados contra el código.
Análisis estático en la integración continua
El análisis estático se realiza a menudo durante el proceso de integración continua (CI) para generar un informe de los problemas de conformidad que puede ser revisado para recibir una visión objetiva de la base de código a lo largo del tiempo.
Algunas personas utilizan el análisis estático como una medida objetiva de la calidad de su código configurando la herramienta de análisis estático para que sólo mida partes específicas del código y sólo informe sobre un subconjunto de reglas.
La objetividad la proporcionan las reglas utilizadas, ya que éstas no varían en su evaluación del código a lo largo del tiempo. Evidentemente, la combinación de reglas utilizadas y su configuración es una decisión subjetiva y diferentes equipos deciden utilizar diferentes reglas en diferentes momentos.
Hacer que el análisis estático se realice en CI es útil, pero podría retrasar la retroalimentación al programador. Los programadores no reciben retroalimentación cuando codifican, reciben retroalimentación más tarde cuando el código se ejecuta a través de la herramienta de Análisis Estático. Otro efecto secundario de ejecutar el Análisis Estático en CI es que los resultados son más fáciles de ignorar.
Para ayudar a que los equipos presten más atención a los resultados del Análisis Estático suele ser posible configurar una métrica de umbral en el proceso de construcción para que falle la construcción si se supera la métrica, por ejemplo, un número de reglas disparadas.
Análisis estático en el IDE
Para recibir la retroalimentación más rápidamente, hay muchos plugins de IDE que ejecutan las reglas de Análisis Estático en el IDE bajo demanda, o periódicamente a medida que el código cambia.
Las violaciones de las reglas se pueden ver en el IDE mientras el programador está escribiendo el código, y para hacer que las reglas sean más difíciles de ignorar, las violaciones se pueden configurar para que se muestren como código subrayado en el editor.
Personalmente encuentro que es una forma útil de mejorar mi codificación, particularmente cuando se trabaja con una nueva biblioteca que está cubierta por la herramienta de Análisis Estático. Aunque puede ser 'ruidoso' con falsos positivos, o reglas que no te interesan. Pero esto se soluciona dando el paso extra de configurar la herramienta de Análisis Estático para ignorar ciertas reglas.
Corrección de código basada en reglas de análisis estático
Con la mayoría de las herramientas de Análisis Estático, la fijación de la regla se deja al programador, por lo que éste tiene que entender la causa de la violación de la regla y cómo solucionarla.
Muy pocas herramientas de análisis estático incluyen también la posibilidad de corregir las infracciones porque la corrección suele ser contextual al equipo y a la tecnología utilizada y a sus estilos de codificación acordados.
Normas por defecto
La falsa confianza en la calidad de las reglas puede surgir cuando las herramientas de análisis estático vienen con reglas por defecto, es tentador creer que cubren todos los problemas que un programador puede encontrar, y todas las circunstancias en las que esa regla debería aplicarse. A veces, las circunstancias en las que debería aplicarse una regla pueden ser sutiles y no ser fáciles de detectar.
La esperanza es que, al utilizar una herramienta de análisis estático e investigar las reglas y las violaciones con más detalle, los programadores desarrollen la habilidad de detectar y evitar el problema en el contexto de su dominio específico.
Cuando el dominio requiere reglas contextuales, es posible que las herramientas de análisis estático no tengan ninguna regla que coincida con su dominio o biblioteca y, además, las herramientas pueden ser a menudo difíciles de configurar y ampliar.
Molestias
Ninguna de estas "molestias" es insuperable:
- falsos positivos
- falta de arreglos
- configuración para ignorar las reglas
- añadir reglas específicas del contexto
Pero a menudo se utilizan como excusas para evitar el uso de herramientas de Análisis Estático en primer lugar, lo cual es una pena porque el uso del Análisis Estático puede ser enormemente útil, como una forma de:
- destacar los mejores enfoques para los desarrolladores junior
- Obtenga información rápida sobre las infracciones claras de la codificación
- identificar problemas oscuros que el programador no ha encontrado antes
- reforzar que el programador ha adoptado un buen enfoque de codificación (cuando no se denuncian infracciones)
Herramientas de análisis estático basadas en IDE
Como colaborador individual de un proyecto, me gusta utilizar herramientas de análisis estático que se ejecutan desde el IDE para recibir rápidamente información sobre mi código.
Esto complementa cualquier proceso de revisión de solicitudes de extracción y la integración de CI que pueda tener un proyecto.
Intento identificar las herramientas que me dan ventaja y mejoran mi flujo de trabajo individual.
Cuando las herramientas se ejecutan en el IDE, debido a que tienden a compartir la misma interfaz gráfica de usuario y el mismo enfoque de configuración, puede ser tentador verlas indistintamente.
Las herramientas pueden tener funcionalidades o conjuntos de reglas que se solapan, pero para obtener el máximo provecho instalo varias herramientas para aprovechar sus puntos fuertes.
Las herramientas IDE de análisis estático que utilizo activamente cuando codifico se enumeran a continuación:
- las inspecciones incorporadas de IntelliJ - patrones de codificación comunes
- SpotBugs - errores comunes
- SonarLint - patrones de uso comunes
- CheckStyle - patrones de estilo comunes
- Sensei de Secure Code Warrior - creación de reglas personalizadas
Los utilizo todos porque funcionan bien juntos para aumentar y complementar a los demás.
Inspecciones de IntelliJ
Si utiliza IntelliJ entonces ya está utilizando sus Inspecciones.
Son reglas de Análisis Estático que se marcan en el IDE. Algunas de ellas también tienen opciones de QuickFix para reescribir el código y solucionar el problema.
Las reglas son configurables en encendido y apagado, y para elegir el nivel de error utilizado para resaltarlo en el IDE.
Hay un montón de buenas inspecciones de IntelliJ. Lo sé porque las he leído mientras escribía esto. Yo utilizo las inspecciones de IntelliJ por defecto y no las he configurado, pero para obtener todo el valor de las inspecciones deberías leerlas, identificar las que son relevantes para tu estilo de codificación y configurar el nivel de advertencia para que las notes en el código.
Lo bueno de las inspecciones de IntelliJ es que vienen gratis con el IDE y ayudan a construir la memoria muscular de:
- notar las advertencias y los errores en el código fuente mientras se escribe el código
- pasar el ratón por encima del código marcado para conocer las infracciones de las normas
- usando alt+enter para aplicar una solución rápida al problema
SpotBugs
El plugin SpotBugs IntelliJ utiliza el Análisis Estático para tratar de alertarle de los errores en su código.
SpotBugs puede ser configurado desde las Preferencias de IntelliJ para escanear su código, las reglas reales utilizadas se pueden encontrar en la pestaña de Detector.
Suelo utilizar SpotBugs después de haber escrito y revisado mi código, entonces ejecutaré el 'Analyze Project Files Including Test Sources'.
Esto me ayuda a identificar errores, código muerto y optimizaciones obvias. También me obliga a investigar algunas de las violaciones marcadas para ayudarme a decidir qué hacer.
SpotBugs encontrará problemas pero no ofrece ninguna acción de QuickFix para intentar resolverlos.
SpotBugs es fácil de configurar y me parece una segunda opinión objetiva útil para consultar en mi IDE.
SonarLint
El plugin SonarLint.
SonarLint se puede configurar desde las Preferencias de IntelliJ para seleccionar las reglas con las que se valida el código.
Por defecto, SonarLint se ejecuta en tiempo real y muestra los problemas del código actual que se está editando.
SonarLint no ofrece soluciones rápidas, pero la documentación asociada a los informes de infracción suele ser clara y estar bien documentada.
En el pasado, SonarLint me resultó útil para alertarme de las nuevas características de Java que conocía en las nuevas versiones de Java.
CheckStyle
El plugin CheckStyle ofrece una mezcla de reglas de formato y de calidad de código.
El plugin CheckStyle viene con 'Sun Checks' y 'Google Checks'.
Las definiciones de las mismas se pueden encontrar fácilmente en Internet.
CheckStyle añade el mayor valor cuando un proyecto ha dedicado tiempo a crear su propio conjunto de reglas. Entonces el plugin del IDE puede ser configurado para usar ese conjunto de reglas y los programadores pueden realizar un análisis, antes de enviar el código a CI.
CheckStyle se utiliza muy a menudo como un plugin de fallo de construcción para los procesos de CI cuando el número de violaciones de CheckStyle supera un umbral.
Sensei
Sensei utiliza el análisis estático basado en un árbol de sintaxis abstracto (AST) para cotejar el código y crear QuickFixes, lo que permite identificar de forma muy específica el código con problemas.
El AST permite que los QuickFixes asociados a una receta entiendan el código circundante, por ejemplo, cuando se añade una nueva clase en el código, cualquier importación para esa clase sólo se añadirá al archivo fuente una vez, y no para cada sustitución.
Sensei se creó para facilitar la creación de reglas de concordancia personalizadas que pueden no existir, o que serían difíciles de configurar, en otras herramientas.
En lugar de modificar un archivo de configuración, toda la configuración puede realizarse en la GUI. Al crear nuevas recetas, la interfaz gráfica de usuario permite ver fácilmente a qué código corresponde la receta. Y al definir las QuickFixes se puede comparar inmediatamente el estado del código antes y después. Esto facilita la creación de recetas muy contextuales, es decir, únicas para equipos, o tecnología, e incluso para programadores individuales.
Utilizo Sensei en combinación con otras herramientas de Análisis Estático, por ejemplo, la mayoría de las herramientas de Análisis Estático encontrarán problemas, pero no los arreglarán. Un caso de uso común para Sensei es replicar la búsqueda de coincidencias de la otra herramienta en Sensei, y ampliarla con una corrección rápida. Esto tiene la ventaja de que la corrección personalizada aplicada ya cumple con los estándares de codificación para su proyecto.
Periódicamente me encuentro creando Sensei recetas que ya existen en el conjunto de IntelliJ Intensions porque el informe de Intension no coincide del todo con el contexto que he creado o porque el QuickFix proporcionado por IntelliJ no coincide con el patrón de código que quiero utilizar.
Aumento las herramientas existentes, en lugar de intentar sustituirlas por completo.
Sensei también puede ser muy útil cuando se identifica una variante contextual de una regla común, por ejemplo, si se utiliza una biblioteca SQL no soportada por la herramienta de Análisis Estático, pero las reglas SQL comunes en el motor de Análisis Estático siguen siendo aplicables, entonces se pueden crear variantes específicas de la biblioteca de esas reglas utilizando Sensei.
Sensei no viene de fábrica con un montón de recetas genéricas como las herramientas de análisis estático mencionadas, su punto fuerte es facilitar la creación de nuevas recetas, completas con QuickFixes configuradas para adaptarse a su estilo de codificación y casos de uso específicos.
NOTA: estamos trabajando en un repositorio público de recetas para cubrir casos de uso genéricos, y puede encontrarlo aquí.
Resumen
Tiendo a elegir herramientas que funcionen juntas, que sean configurables y que sean fáciles de ampliar para adaptarse a mi contexto específico. Llevo años utilizando herramientas de análisis estático en el IDE para ayudarme a identificar problemas y aprender más sobre los lenguajes de programación y las bibliotecas que utilizo.
Utilizo todas las herramientas mencionadas en combinación:
- IntelliJ Intentions ayuda a señalar los problemas de código más comunes desde el principio, a menudo con QuickFixes asociados.
- SpotBugs encuentra errores sencillos que podría haber pasado por alto y me avisa de los problemas de rendimiento.
- SonarLint identifica características de Java que desconocía y me indica formas adicionales de modelar mi código.
- CheckStyle me ayuda a ajustarme a un estilo de codificación acordado que también se aplica durante la IC.
- Sensei me ayuda a crear QuickFixes para aumentar los escenarios comunes encontrados por las herramientas de Análisis Estático y crear recetas específicas de proyectos o tecnologías que pueden ser difíciles de configurar en otra herramienta.
---
Instale Sensei desde IntelliJ usando "Preferences \ Plugins" (Mac) o "Settings \ Plugins" (Windows) y luego sólo busque "sensei secure code".
Puedes encontrar un repositorio de código de ejemplo y recetas para casos de uso comunes en la cuenta de GitHub de Secure Code Warrior , en el proyecto `sensei-blog-examples`.
https://github.com/securecodewarrior/sensei-blog-examples
Alan Richardson
Artículos relacionados que recomendamos
Artículos relacionados que recomendamos
Sumérjase en nuestras últimas ideas sobre codificación segura en el blog.
Nuestra amplia biblioteca de recursos tiene como objetivo potenciar el enfoque humano de la mejora de la codificación segura.
Obtenga las últimas investigaciones sobre la seguridad impulsada por los desarrolladores
Nuestra amplia biblioteca de recursos está repleta de recursos útiles, desde libros blancos hasta seminarios web, que le ayudarán a iniciarse en la codificación segura orientada a los desarrolladores. Explórela ahora.
¿Qué es el análisis estático?
¿Qué es el análisis estático?
El análisis estático es el análisis automatizado del código fuente sin ejecutar la aplicación.
Cuando el análisis se realiza durante la ejecución del programa, se conoce como Análisis Dinámico.
El análisis estático se utiliza a menudo para detectar:
- Vulnerabilidades de seguridad.
- Problemas de rendimiento.
- Incumplimiento de las normas.
- Uso de construcciones de programación obsoletas.
¿Cómo funciona una herramienta de análisis estático?
El concepto básico común a todas las herramientas de análisis estático es buscar en el código fuente para identificar patrones de codificación específicos que tengan algún tipo de advertencia o información asociada.
Esto podría ser tan simple como "Las clases de prueba de JUnit 5 no necesitan ser 'públicas'". O algo complejo de identificar como "Se está utilizando una entrada de cadena no fiable en una sentencia de ejecución SQL".
Las herramientas de análisis estático varían en la forma de implementar esta funcionalidad.
- tecnología de análisis de código fuente para crear un árbol de sintaxis abstracta (AST),
- texto Coincidencia de expresiones regulares,
- una combinación de las anteriores.
La concordancia de expresiones regulares en el texto es muy flexible, fácil de escribir reglas de concordancia, pero a menudo puede conducir a una gran cantidad de falsos positivos y las reglas de concordancia ignoran el contexto del código circundante.
La concordancia AST trata el código fuente como código de programa, y no sólo como archivos llenos de texto, lo que permite una concordancia más específica y contextual y puede reducir el número de falsos positivos reportados contra el código.
Análisis estático en la integración continua
El análisis estático se realiza a menudo durante el proceso de integración continua (CI) para generar un informe de los problemas de conformidad que puede ser revisado para recibir una visión objetiva de la base de código a lo largo del tiempo.
Algunas personas utilizan el análisis estático como una medida objetiva de la calidad de su código configurando la herramienta de análisis estático para que sólo mida partes específicas del código y sólo informe sobre un subconjunto de reglas.
La objetividad la proporcionan las reglas utilizadas, ya que éstas no varían en su evaluación del código a lo largo del tiempo. Evidentemente, la combinación de reglas utilizadas y su configuración es una decisión subjetiva y diferentes equipos deciden utilizar diferentes reglas en diferentes momentos.
Hacer que el análisis estático se realice en CI es útil, pero podría retrasar la retroalimentación al programador. Los programadores no reciben retroalimentación cuando codifican, reciben retroalimentación más tarde cuando el código se ejecuta a través de la herramienta de Análisis Estático. Otro efecto secundario de ejecutar el Análisis Estático en CI es que los resultados son más fáciles de ignorar.
Para ayudar a que los equipos presten más atención a los resultados del Análisis Estático suele ser posible configurar una métrica de umbral en el proceso de construcción para que falle la construcción si se supera la métrica, por ejemplo, un número de reglas disparadas.
Análisis estático en el IDE
Para recibir la retroalimentación más rápidamente, hay muchos plugins de IDE que ejecutan las reglas de Análisis Estático en el IDE bajo demanda, o periódicamente a medida que el código cambia.
Las violaciones de las reglas se pueden ver en el IDE mientras el programador está escribiendo el código, y para hacer que las reglas sean más difíciles de ignorar, las violaciones se pueden configurar para que se muestren como código subrayado en el editor.
Personalmente encuentro que es una forma útil de mejorar mi codificación, particularmente cuando se trabaja con una nueva biblioteca que está cubierta por la herramienta de Análisis Estático. Aunque puede ser 'ruidoso' con falsos positivos, o reglas que no te interesan. Pero esto se soluciona dando el paso extra de configurar la herramienta de Análisis Estático para ignorar ciertas reglas.
Corrección de código basada en reglas de análisis estático
Con la mayoría de las herramientas de Análisis Estático, la fijación de la regla se deja al programador, por lo que éste tiene que entender la causa de la violación de la regla y cómo solucionarla.
Muy pocas herramientas de análisis estático incluyen también la posibilidad de corregir las infracciones porque la corrección suele ser contextual al equipo y a la tecnología utilizada y a sus estilos de codificación acordados.
Normas por defecto
La falsa confianza en la calidad de las reglas puede surgir cuando las herramientas de análisis estático vienen con reglas por defecto, es tentador creer que cubren todos los problemas que un programador puede encontrar, y todas las circunstancias en las que esa regla debería aplicarse. A veces, las circunstancias en las que debería aplicarse una regla pueden ser sutiles y no ser fáciles de detectar.
La esperanza es que, al utilizar una herramienta de análisis estático e investigar las reglas y las violaciones con más detalle, los programadores desarrollen la habilidad de detectar y evitar el problema en el contexto de su dominio específico.
Cuando el dominio requiere reglas contextuales, es posible que las herramientas de análisis estático no tengan ninguna regla que coincida con su dominio o biblioteca y, además, las herramientas pueden ser a menudo difíciles de configurar y ampliar.
Molestias
Ninguna de estas "molestias" es insuperable:
- falsos positivos
- falta de arreglos
- configuración para ignorar las reglas
- añadir reglas específicas del contexto
Pero a menudo se utilizan como excusas para evitar el uso de herramientas de Análisis Estático en primer lugar, lo cual es una pena porque el uso del Análisis Estático puede ser enormemente útil, como una forma de:
- destacar los mejores enfoques para los desarrolladores junior
- Obtenga información rápida sobre las infracciones claras de la codificación
- identificar problemas oscuros que el programador no ha encontrado antes
- reforzar que el programador ha adoptado un buen enfoque de codificación (cuando no se denuncian infracciones)
Herramientas de análisis estático basadas en IDE
Como colaborador individual de un proyecto, me gusta utilizar herramientas de análisis estático que se ejecutan desde el IDE para recibir rápidamente información sobre mi código.
Esto complementa cualquier proceso de revisión de solicitudes de extracción y la integración de CI que pueda tener un proyecto.
Intento identificar las herramientas que me dan ventaja y mejoran mi flujo de trabajo individual.
Cuando las herramientas se ejecutan en el IDE, debido a que tienden a compartir la misma interfaz gráfica de usuario y el mismo enfoque de configuración, puede ser tentador verlas indistintamente.
Las herramientas pueden tener funcionalidades o conjuntos de reglas que se solapan, pero para obtener el máximo provecho instalo varias herramientas para aprovechar sus puntos fuertes.
Las herramientas IDE de análisis estático que utilizo activamente cuando codifico se enumeran a continuación:
- las inspecciones incorporadas de IntelliJ - patrones de codificación comunes
- SpotBugs - errores comunes
- SonarLint - patrones de uso comunes
- CheckStyle - patrones de estilo comunes
- Sensei de Secure Code Warrior - creación de reglas personalizadas
Los utilizo todos porque funcionan bien juntos para aumentar y complementar a los demás.
Inspecciones de IntelliJ
Si utiliza IntelliJ entonces ya está utilizando sus Inspecciones.
Son reglas de Análisis Estático que se marcan en el IDE. Algunas de ellas también tienen opciones de QuickFix para reescribir el código y solucionar el problema.
Las reglas son configurables en encendido y apagado, y para elegir el nivel de error utilizado para resaltarlo en el IDE.
Hay un montón de buenas inspecciones de IntelliJ. Lo sé porque las he leído mientras escribía esto. Yo utilizo las inspecciones de IntelliJ por defecto y no las he configurado, pero para obtener todo el valor de las inspecciones deberías leerlas, identificar las que son relevantes para tu estilo de codificación y configurar el nivel de advertencia para que las notes en el código.
Lo bueno de las inspecciones de IntelliJ es que vienen gratis con el IDE y ayudan a construir la memoria muscular de:
- notar las advertencias y los errores en el código fuente mientras se escribe el código
- pasar el ratón por encima del código marcado para conocer las infracciones de las normas
- usando alt+enter para aplicar una solución rápida al problema
SpotBugs
El plugin SpotBugs IntelliJ utiliza el Análisis Estático para tratar de alertarle de los errores en su código.
SpotBugs puede ser configurado desde las Preferencias de IntelliJ para escanear su código, las reglas reales utilizadas se pueden encontrar en la pestaña de Detector.
Suelo utilizar SpotBugs después de haber escrito y revisado mi código, entonces ejecutaré el 'Analyze Project Files Including Test Sources'.
Esto me ayuda a identificar errores, código muerto y optimizaciones obvias. También me obliga a investigar algunas de las violaciones marcadas para ayudarme a decidir qué hacer.
SpotBugs encontrará problemas pero no ofrece ninguna acción de QuickFix para intentar resolverlos.
SpotBugs es fácil de configurar y me parece una segunda opinión objetiva útil para consultar en mi IDE.
SonarLint
El plugin SonarLint.
SonarLint se puede configurar desde las Preferencias de IntelliJ para seleccionar las reglas con las que se valida el código.
Por defecto, SonarLint se ejecuta en tiempo real y muestra los problemas del código actual que se está editando.
SonarLint no ofrece soluciones rápidas, pero la documentación asociada a los informes de infracción suele ser clara y estar bien documentada.
En el pasado, SonarLint me resultó útil para alertarme de las nuevas características de Java que conocía en las nuevas versiones de Java.
CheckStyle
El plugin CheckStyle ofrece una mezcla de reglas de formato y de calidad de código.
El plugin CheckStyle viene con 'Sun Checks' y 'Google Checks'.
Las definiciones de las mismas se pueden encontrar fácilmente en Internet.
CheckStyle añade el mayor valor cuando un proyecto ha dedicado tiempo a crear su propio conjunto de reglas. Entonces el plugin del IDE puede ser configurado para usar ese conjunto de reglas y los programadores pueden realizar un análisis, antes de enviar el código a CI.
CheckStyle se utiliza muy a menudo como un plugin de fallo de construcción para los procesos de CI cuando el número de violaciones de CheckStyle supera un umbral.
Sensei
Sensei utiliza el análisis estático basado en un árbol de sintaxis abstracto (AST) para cotejar el código y crear QuickFixes, lo que permite identificar de forma muy específica el código con problemas.
El AST permite que los QuickFixes asociados a una receta entiendan el código circundante, por ejemplo, cuando se añade una nueva clase en el código, cualquier importación para esa clase sólo se añadirá al archivo fuente una vez, y no para cada sustitución.
Sensei se creó para facilitar la creación de reglas de concordancia personalizadas que pueden no existir, o que serían difíciles de configurar, en otras herramientas.
En lugar de modificar un archivo de configuración, toda la configuración puede realizarse en la GUI. Al crear nuevas recetas, la interfaz gráfica de usuario permite ver fácilmente a qué código corresponde la receta. Y al definir las QuickFixes se puede comparar inmediatamente el estado del código antes y después. Esto facilita la creación de recetas muy contextuales, es decir, únicas para equipos, o tecnología, e incluso para programadores individuales.
Utilizo Sensei en combinación con otras herramientas de Análisis Estático, por ejemplo, la mayoría de las herramientas de Análisis Estático encontrarán problemas, pero no los arreglarán. Un caso de uso común para Sensei es replicar la búsqueda de coincidencias de la otra herramienta en Sensei, y ampliarla con una corrección rápida. Esto tiene la ventaja de que la corrección personalizada aplicada ya cumple con los estándares de codificación para su proyecto.
Periódicamente me encuentro creando Sensei recetas que ya existen en el conjunto de IntelliJ Intensions porque el informe de Intension no coincide del todo con el contexto que he creado o porque el QuickFix proporcionado por IntelliJ no coincide con el patrón de código que quiero utilizar.
Aumento las herramientas existentes, en lugar de intentar sustituirlas por completo.
Sensei también puede ser muy útil cuando se identifica una variante contextual de una regla común, por ejemplo, si se utiliza una biblioteca SQL no soportada por la herramienta de Análisis Estático, pero las reglas SQL comunes en el motor de Análisis Estático siguen siendo aplicables, entonces se pueden crear variantes específicas de la biblioteca de esas reglas utilizando Sensei.
Sensei no viene de fábrica con un montón de recetas genéricas como las herramientas de análisis estático mencionadas, su punto fuerte es facilitar la creación de nuevas recetas, completas con QuickFixes configuradas para adaptarse a su estilo de codificación y casos de uso específicos.
NOTA: estamos trabajando en un repositorio público de recetas para cubrir casos de uso genéricos, y puede encontrarlo aquí.
Resumen
Tiendo a elegir herramientas que funcionen juntas, que sean configurables y que sean fáciles de ampliar para adaptarse a mi contexto específico. Llevo años utilizando herramientas de análisis estático en el IDE para ayudarme a identificar problemas y aprender más sobre los lenguajes de programación y las bibliotecas que utilizo.
Utilizo todas las herramientas mencionadas en combinación:
- IntelliJ Intentions ayuda a señalar los problemas de código más comunes desde el principio, a menudo con QuickFixes asociados.
- SpotBugs encuentra errores sencillos que podría haber pasado por alto y me avisa de los problemas de rendimiento.
- SonarLint identifica características de Java que desconocía y me indica formas adicionales de modelar mi código.
- CheckStyle me ayuda a ajustarme a un estilo de codificación acordado que también se aplica durante la IC.
- Sensei me ayuda a crear QuickFixes para aumentar los escenarios comunes encontrados por las herramientas de Análisis Estático y crear recetas específicas de proyectos o tecnologías que pueden ser difíciles de configurar en otra herramienta.
---
Instale Sensei desde IntelliJ usando "Preferences \ Plugins" (Mac) o "Settings \ Plugins" (Windows) y luego sólo busque "sensei secure code".
Puedes encontrar un repositorio de código de ejemplo y recetas para casos de uso comunes en la cuenta de GitHub de Secure Code Warrior , en el proyecto `sensei-blog-examples`.
https://github.com/securecodewarrior/sensei-blog-examples
