¿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.
Si el análisis se lleva a cabo durante la ejecución del programa, se denomina análisis dinámico.
El análisis estático se utiliza con frecuencia para detectar lo siguiente:
- Brechas 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 consiste en buscar en el código fuente determinados patrones de codificación a los que se asigna una advertencia o información.
Dies könnte so einfach sein wie „JUnit 5-Testklassen müssen nicht 'öffentlich' sein“. Oder etwas, das komplex zu identifizieren ist, wie „Nicht vertrauenswürdige Zeichenketteningabe, die in einer SQL-Ausführungsanweisung verwendet wird“.
Las herramientas de análisis estático difieren en la forma en que implementan esta funcionalidad.
- Tecnología de análisis de código fuente para la creación de un árbol sintáctico abstracto (AST).
- Comparación de texto con expresiones regulares,
- una combinación de lo anterior.
La comparación de expresiones regulares en texto es muy flexible, es fácil escribir reglas para la comparación, pero a menudo puede dar lugar a muchos resultados falsos positivos, y las reglas de comparación no conocen el contexto del código circundante.
El AST-Matching trata el código fuente como código de programa y no solo como archivos llenos de texto. Esto permite una comparación más específica y contextualizada, y puede reducir el número de falsos positivos que se notifican contra el código.
Análisis estático en integración continua
Los análisis estáticos se suelen realizar durante el proceso de integración continua (CI) para generar un informe sobre los problemas de cumplimiento que se puede revisar con el fin de obtener una visión general objetiva de la base de código a lo largo del tiempo.
Algunos usuarios utilizan el análisis estático como medida objetiva de la calidad de su código, configurando la herramienta de análisis estático para que solo se midan determinadas partes del código y solo se informe sobre un subconjunto de reglas.
La objetividad está garantizada por las reglas utilizadas, ya que estas no cambian con el tiempo en su evaluación del código. Es evidente que la combinación de las reglas utilizadas y su configuración es una decisión subjetiva, y diferentes equipos optan por utilizar diferentes reglas en diferentes momentos.
Es útil realizar el análisis estático en CI, pero puede retrasar la retroalimentación al programador. Los programadores no reciben retroalimentación durante la programación, sino más tarde, cuando el código pasa por la herramienta de análisis estático. Otro efecto secundario de la ejecución del análisis estático en CI es que los resultados son más fáciles de ignorar.
Para que los equipos presten más atención a los resultados del análisis estático, normalmente es posible configurar una métrica de umbral en el proceso de compilación, de modo que la compilación falle si se supera la métrica, por ejemplo, una serie de reglas activadas.
Análisis estático en el IDE
Para obtener comentarios más rápidamente, existen muchos complementos IDE que ejecutan las reglas del análisis estático en el IDE cuando es necesario o a intervalos regulares, cuando cambia el código.
Las infracciones de las reglas pueden mostrarse en el IDE mientras el programador escribe el código. Para dificultar el incumplimiento de las reglas, las infracciones a menudo pueden configurarse para que se muestren en el editor como código subrayado.
Personalmente, creo que es un método útil para mejorar mi código, especialmente cuando trabajo con una nueva biblioteca cubierta por la herramienta de análisis estático. Sin embargo, puede resultar «ruidoso» en caso de falsos positivos o reglas que no le interesen. No obstante, esto se soluciona dando un paso adicional para configurar la herramienta de análisis estático de modo que se ignoren determinadas reglas.
Corrección de código basada en reglas de análisis estático
En la mayoría de las herramientas de análisis estático, la corrección de la regla queda a cargo del programador, por lo que este debe comprender la causa de la infracción de la regla y saber cómo solucionarla.
Muy pocas herramientas de análisis estático ofrecen también la posibilidad de corregir las infracciones, ya que la corrección suele depender del equipo, la tecnología utilizada y los estilos de codificación acordados.
Reglas estándar
Se puede generar una confianza errónea en la calidad de las reglas cuando las herramientas de análisis estático están equipadas con reglas estándar. Es tentador creer que cubren todos los problemas con los que podría encontrarse un programador y todas las circunstancias en las que debería aplicarse la regla. A veces, las circunstancias en las que debería aplicarse una regla son sutiles y pueden no ser fáciles de detectar.
Existe la esperanza de que, mediante el uso de una herramienta de análisis estático y un examen más detallado de las reglas y las infracciones, los programadores desarrollen la capacidad de reconocer y evitar el problema en el contexto de su dominio específico.
Si el dominio requiere reglas de contexto, es posible que las herramientas de análisis estático no dispongan de reglas que se ajusten a su dominio o biblioteca y, además, estas herramientas suelen ser difíciles de configurar y ampliar.
Molestias
Ninguno de estos «molestias» es insuperable:
- falso positivo
- Falta de correcciones
- Configuración para ignorar reglas
- Añadir reglas específicas del contexto
Sin embargo, a menudo se utilizan como excusas para evitar desde el principio el uso de herramientas de análisis estático, lo cual es una lástima, ya que el uso del análisis estático puede ser extremadamente útil para:
- Destacar mejores enfoques para los desarrolladores jóvenes.
- Reciba comentarios rápidos sobre infracciones claras de codificación.
- Identifique problemas oscuros con los que el programador nunca se ha encontrado.
- Confirmar que el programador ha elegido un buen enfoque de codificación (siempre que no se hayan notificado infracciones).
Herramientas de análisis estático basadas en IDE
Como colaborador individual en un proyecto, me gusta utilizar herramientas de análisis estático que se ejecutan en el IDE, lo que me permite obtener una respuesta rápida 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 encontrar herramientas que me proporcionen una ventaja y mejoren mi flujo de trabajo individual.
Cuando las herramientas se ejecutan en el IDE, puede resultar tentador considerarlas sinónimos, ya que suelen utilizar la misma interfaz gráfica de usuario básica y el mismo enfoque de configuración.
Las herramientas pueden tener funciones o conjuntos de reglas que se superponen, pero para obtener el máximo beneficio, instalo varias herramientas para aprovechar sus puntos fuertes.
Las herramientas IDE para análisis estáticos que utilizo activamente al programar se enumeran a continuación:
- Las inspecciones integradas de IntelliJ: patrones de codificación habituales
- SpotBugs — errores frecuentes
- SonarLint: patrones generales de uso
- CheckStyle: patrones de estilo habituales
- Sensei Secure Code Warrior creación de reglas personalizadas
Las utilizo todas porque funcionan bien juntas, se complementan y se complementan entre sí.
Inspecciones de IntelliJ
Si utiliza IntelliJ, ya está utilizando sus inspecciones.
Estas son reglas para análisis estáticos que se marcan en el IDE. Algunas de ellas también disponen de opciones QuickFix con las que se puede reescribir el código para solucionar el problema.
Las reglas se pueden activar y desactivar, y puede seleccionar el nivel de error con el que se resaltan en el IDE.
Hay muchas inspecciones buenas en IntelliJ. Lo sé porque las he leído mientras escribo esto. Utilizo las inspecciones de IntelliJ como valores predeterminados y no las he configurado, pero para sacar el máximo partido a las inspecciones, debe leerlas, identificar las que son relevantes para su estilo de codificación y configurar el nivel de advertencia para que las note en el código.
Lo mejor de las inspecciones de IntelliJ es que están incluidas de forma gratuita en el IDE y ayudan a desarrollar la memoria muscular de:
- Detección de advertencias y errores en el código fuente mientras se escribe el código.
- Mueva el puntero del ratón sobre el código marcado para conocer las infracciones de las normas.
- Utilice Alt+Intro para aplicar una solución rápida al problema.
Detectar errores
Detectar errores El complemento IntelliJ utiliza el análisis estático para alertarle sobre errores en su código.
SpotBugs se pueden configurar en los ajustes de IntelliJ para que se analice su código. Las reglas que se utilizan realmente se encuentran en la pestaña Detector.
Suelo utilizar SpotBugs después de escribir y revisar mi código. A continuación, ejecuto la opción «Analizar archivos de proyecto, incluidas las fuentes de prueba».
Esto me ayuda a identificar errores, código obsoleto y optimizaciones obvias. También me obliga a investigar algunas de las infracciones notificadas para ayudarme a decidir qué hacer.
SpotBugs detecta problemas, pero no ofrece acciones QuickFix para intentar resolverlos.
SpotBugs es fácil de configurar y lo considero una segunda opinión objetiva y útil que puedo obtener en mi IDE.
Sonar Lint
El complemento Sonar Lint.
SonarLint se puede configurar en los ajustes de IntelliJ para seleccionar las reglas según las cuales se valida el código.
De forma predeterminada, SonarLint se ejecuta en tiempo real y muestra los problemas del código actual que está editando.
SonarLint no ofrece soluciones rápidas, pero la documentación relacionada con los informes de infracciones suele ser clara y estar bien documentada.
En el pasado, SonarLint me ha resultado útil para informarme sobre nuevas funciones de Java que no conocía en las versiones más recientes de Java.
Seguir comprobando
Comprobar el estilo El complemento ofrece una combinación de reglas de formato y calidad del código.
El complemento CheckStyle se suministra en un paquete con «Sun Checks» y «Google Checks».
Las definiciones de estos términos se pueden encontrar fácilmente en Internet.
CheckStyle ofrece el mayor valor añadido cuando un proyecto ha dedicado tiempo a crear su propio conjunto de reglas. Entonces, el complemento IDE se puede configurar para que utilice este conjunto de reglas y los programadores pueden realizar un análisis antes de transferir el código a CI.
CheckStyle se utiliza muy a menudo como complemento de fallo de compilación para procesos de CI cuando el número de infracciones de CheckStyle supera un umbral determinado.
Sensei
Sensei utiliza un análisis estático basado en un árbol sintáctico abstracto (AST) para comparar código y crear QuickFixes. Esto permite identificar de forma muy específica el código que presenta problemas.
El AST permite a QuickFixes, que están asignados a una receta, comprender el código circundante, por ejemplo, cuando se añade una nueva clase al código, cada importación para esta clase se añade solo una vez al archivo fuente y no para cada sustitución.
Sensei desarrollado para facilitar la creación de reglas de coincidencia personalizadas que podrían no existir en otras herramientas o que serían difíciles de configurar.
En lugar de modificar un archivo de configuración, toda la configuración se puede realizar en la interfaz gráfica de usuario. Al crear nuevas recetas, la interfaz gráfica de usuario permite identificar fácilmente a qué código se adapta la receta. Y al definir las soluciones rápidas, se puede comparar inmediatamente el estado del código antes y después. Esto facilita la creación de recetas muy contextuales, es decir, específicas para equipos, tecnologías e incluso programadores individuales.
Utilizo Sensei combinación con otras herramientas de análisis estático, por ejemplo, la mayoría de las herramientas de análisis estático detectan problemas, pero no los solucionan. Un caso de uso frecuente de Sensei Sensei la búsqueda adecuada de la otra herramienta en Sensei y ampliarla con una solución rápida. Esto tiene la ventaja de que la solución personalizada aplicada ya cumple con los estándares de codificación de su proyecto.
Periódicamente creo Sensei que ya están incluidas en el conjunto IntelliJ Intensions, porque el informe Intension no se ajusta del todo al contexto que he creado o porque la solución rápida proporcionada por IntelliJ no se ajusta al patrón de código que quiero utilizar.
Complemento las herramientas existentes, en lugar de intentar sustituirlas por completo.
Sensei también Sensei ser muy útil si identifica una variante contextual de una regla general, por ejemplo, si utiliza una biblioteca SQL que no es compatible con la herramienta de análisis estático, pero las reglas SQL generales del motor de análisis estático siguen siendo válidas, entonces puede utilizar Sensei para crear variantes Sensei de estas reglas.
Sensei no Sensei muchas recetas genéricas como las herramientas de análisis estático mencionadas. Su punto fuerte es que facilita la creación de nuevas recetas, completas con QuickFixes configuradas para adaptarse a su estilo de codificación específico y a sus casos de uso.
NOTA: Estamos trabajando en un archivo público con recetas para cubrir casos de uso genéricos, y lo encontrarás aquí.
Resumen
Tiendo a elegir herramientas que funcionen juntas, sean configurables y 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 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 detectar inmediatamente los problemas de código más frecuentes, a menudo con las soluciones rápidas correspondientes.
- SpotBugs encuentra errores sencillos que quizá se me hayan pasado por alto y me avisa de problemas de rendimiento.
- SonarLint identifica funciones Java que yo desconocía y me pide que modele mi código adicionalmente.
- CheckStyle me ayuda a mantener un estilo de codificación acordado, que también se aplica durante la integración continua.
- Sensei me Sensei a crear QuickFixes para ampliar escenarios comunes que se encuentran con herramientas de análisis estático y a crear recetas específicas para proyectos o tecnologías que son difíciles de configurar en otras herramientas.
---
Instale Sensei IntelliJ con «Preferences\ Plugins» (Mac) o «Settings\ Plugins» (Windows) y, a continuación, busqueSensei Code».
Encontrará un repositorio con código de ejemplo y recetas para casos de uso habituales en la cuenta de GitHub de Secure Code Warrior proyectosensei».
https://github.com/securecodewarrior/sensei-blog-examples
Descubra más sobre el análisis estático y cómo puede ayudarle a escribir un código mejor con ejemplos de 5 enfoques basados en IDE y complementos.
Alan Richardson cuenta con más de veinte años de experiencia profesional en TI, trabajando como desarrollador y en todos los niveles de la jerarquía de pruebas, desde probador hasta jefe de pruebas. Jefe de Relaciones con los Desarrolladores en Secure Code Warrior, trabaja directamente con los equipos, para mejorar el desarrollo de un código seguro de calidad. Alan es autor de cuatro libros, entre ellos "Dear Evil Tester" y "Java For Testers". Alan también ha creado una formación en línea courses para ayudar a la gente a aprender las pruebas técnicas de la web y Selenium WebDriver con Java. Alan publica sus escritos y vídeos de formación en SeleniumSimplified.com, EvilTester.com, JavaForTesters.com, y CompendiumDev.co.uk.
Secure Code Warrior a disposición de su empresa para ayudarle a proteger el código durante todo el ciclo de desarrollo de software y crear una cultura en la que la ciberseguridad sea una prioridad. Tanto si es responsable de seguridad de aplicaciones, desarrollador, responsable de seguridad de la información o cualquier otra persona relacionada con la seguridad, podemos ayudar a su empresa a reducir los riesgos asociados al código inseguro.
Reservar una demostración
Alan Richardson cuenta con más de veinte años de experiencia profesional en TI, trabajando como desarrollador y en todos los niveles de la jerarquía de pruebas, desde probador hasta jefe de pruebas. Jefe de Relaciones con los Desarrolladores en Secure Code Warrior, trabaja directamente con los equipos, para mejorar el desarrollo de un código seguro de calidad. Alan es autor de cuatro libros, entre ellos "Dear Evil Tester" y "Java For Testers". Alan también ha creado una formación en línea courses para ayudar a la gente a aprender las pruebas técnicas de la web y Selenium WebDriver con Java. Alan publica sus escritos y vídeos de formación en SeleniumSimplified.com, EvilTester.com, JavaForTesters.com, y CompendiumDev.co.uk.
¿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.
Si el análisis se lleva a cabo durante la ejecución del programa, se denomina análisis dinámico.
El análisis estático se utiliza con frecuencia para detectar lo siguiente:
- Brechas 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 consiste en buscar en el código fuente determinados patrones de codificación a los que se asigna una advertencia o información.
Dies könnte so einfach sein wie „JUnit 5-Testklassen müssen nicht 'öffentlich' sein“. Oder etwas, das komplex zu identifizieren ist, wie „Nicht vertrauenswürdige Zeichenketteningabe, die in einer SQL-Ausführungsanweisung verwendet wird“.
Las herramientas de análisis estático difieren en la forma en que implementan esta funcionalidad.
- Tecnología de análisis de código fuente para la creación de un árbol sintáctico abstracto (AST).
- Comparación de texto con expresiones regulares,
- una combinación de lo anterior.
La comparación de expresiones regulares en texto es muy flexible, es fácil escribir reglas para la comparación, pero a menudo puede dar lugar a muchos resultados falsos positivos, y las reglas de comparación no conocen el contexto del código circundante.
El AST-Matching trata el código fuente como código de programa y no solo como archivos llenos de texto. Esto permite una comparación más específica y contextualizada, y puede reducir el número de falsos positivos que se notifican contra el código.
Análisis estático en integración continua
Los análisis estáticos se suelen realizar durante el proceso de integración continua (CI) para generar un informe sobre los problemas de cumplimiento que se puede revisar con el fin de obtener una visión general objetiva de la base de código a lo largo del tiempo.
Algunos usuarios utilizan el análisis estático como medida objetiva de la calidad de su código, configurando la herramienta de análisis estático para que solo se midan determinadas partes del código y solo se informe sobre un subconjunto de reglas.
La objetividad está garantizada por las reglas utilizadas, ya que estas no cambian con el tiempo en su evaluación del código. Es evidente que la combinación de las reglas utilizadas y su configuración es una decisión subjetiva, y diferentes equipos optan por utilizar diferentes reglas en diferentes momentos.
Es útil realizar el análisis estático en CI, pero puede retrasar la retroalimentación al programador. Los programadores no reciben retroalimentación durante la programación, sino más tarde, cuando el código pasa por la herramienta de análisis estático. Otro efecto secundario de la ejecución del análisis estático en CI es que los resultados son más fáciles de ignorar.
Para que los equipos presten más atención a los resultados del análisis estático, normalmente es posible configurar una métrica de umbral en el proceso de compilación, de modo que la compilación falle si se supera la métrica, por ejemplo, una serie de reglas activadas.
Análisis estático en el IDE
Para obtener comentarios más rápidamente, existen muchos complementos IDE que ejecutan las reglas del análisis estático en el IDE cuando es necesario o a intervalos regulares, cuando cambia el código.
Las infracciones de las reglas pueden mostrarse en el IDE mientras el programador escribe el código. Para dificultar el incumplimiento de las reglas, las infracciones a menudo pueden configurarse para que se muestren en el editor como código subrayado.
Personalmente, creo que es un método útil para mejorar mi código, especialmente cuando trabajo con una nueva biblioteca cubierta por la herramienta de análisis estático. Sin embargo, puede resultar «ruidoso» en caso de falsos positivos o reglas que no le interesen. No obstante, esto se soluciona dando un paso adicional para configurar la herramienta de análisis estático de modo que se ignoren determinadas reglas.
Corrección de código basada en reglas de análisis estático
En la mayoría de las herramientas de análisis estático, la corrección de la regla queda a cargo del programador, por lo que este debe comprender la causa de la infracción de la regla y saber cómo solucionarla.
Muy pocas herramientas de análisis estático ofrecen también la posibilidad de corregir las infracciones, ya que la corrección suele depender del equipo, la tecnología utilizada y los estilos de codificación acordados.
Reglas estándar
Se puede generar una confianza errónea en la calidad de las reglas cuando las herramientas de análisis estático están equipadas con reglas estándar. Es tentador creer que cubren todos los problemas con los que podría encontrarse un programador y todas las circunstancias en las que debería aplicarse la regla. A veces, las circunstancias en las que debería aplicarse una regla son sutiles y pueden no ser fáciles de detectar.
Existe la esperanza de que, mediante el uso de una herramienta de análisis estático y un examen más detallado de las reglas y las infracciones, los programadores desarrollen la capacidad de reconocer y evitar el problema en el contexto de su dominio específico.
Si el dominio requiere reglas de contexto, es posible que las herramientas de análisis estático no dispongan de reglas que se ajusten a su dominio o biblioteca y, además, estas herramientas suelen ser difíciles de configurar y ampliar.
Molestias
Ninguno de estos «molestias» es insuperable:
- falso positivo
- Falta de correcciones
- Configuración para ignorar reglas
- Añadir reglas específicas del contexto
Sin embargo, a menudo se utilizan como excusas para evitar desde el principio el uso de herramientas de análisis estático, lo cual es una lástima, ya que el uso del análisis estático puede ser extremadamente útil para:
- Destacar mejores enfoques para los desarrolladores jóvenes.
- Reciba comentarios rápidos sobre infracciones claras de codificación.
- Identifique problemas oscuros con los que el programador nunca se ha encontrado.
- Confirmar que el programador ha elegido un buen enfoque de codificación (siempre que no se hayan notificado infracciones).
Herramientas de análisis estático basadas en IDE
Como colaborador individual en un proyecto, me gusta utilizar herramientas de análisis estático que se ejecutan en el IDE, lo que me permite obtener una respuesta rápida 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 encontrar herramientas que me proporcionen una ventaja y mejoren mi flujo de trabajo individual.
Cuando las herramientas se ejecutan en el IDE, puede resultar tentador considerarlas sinónimos, ya que suelen utilizar la misma interfaz gráfica de usuario básica y el mismo enfoque de configuración.
Las herramientas pueden tener funciones o conjuntos de reglas que se superponen, pero para obtener el máximo beneficio, instalo varias herramientas para aprovechar sus puntos fuertes.
Las herramientas IDE para análisis estáticos que utilizo activamente al programar se enumeran a continuación:
- Las inspecciones integradas de IntelliJ: patrones de codificación habituales
- SpotBugs — errores frecuentes
- SonarLint: patrones generales de uso
- CheckStyle: patrones de estilo habituales
- Sensei Secure Code Warrior creación de reglas personalizadas
Las utilizo todas porque funcionan bien juntas, se complementan y se complementan entre sí.
Inspecciones de IntelliJ
Si utiliza IntelliJ, ya está utilizando sus inspecciones.
Estas son reglas para análisis estáticos que se marcan en el IDE. Algunas de ellas también disponen de opciones QuickFix con las que se puede reescribir el código para solucionar el problema.
Las reglas se pueden activar y desactivar, y puede seleccionar el nivel de error con el que se resaltan en el IDE.
Hay muchas inspecciones buenas en IntelliJ. Lo sé porque las he leído mientras escribo esto. Utilizo las inspecciones de IntelliJ como valores predeterminados y no las he configurado, pero para sacar el máximo partido a las inspecciones, debe leerlas, identificar las que son relevantes para su estilo de codificación y configurar el nivel de advertencia para que las note en el código.
Lo mejor de las inspecciones de IntelliJ es que están incluidas de forma gratuita en el IDE y ayudan a desarrollar la memoria muscular de:
- Detección de advertencias y errores en el código fuente mientras se escribe el código.
- Mueva el puntero del ratón sobre el código marcado para conocer las infracciones de las normas.
- Utilice Alt+Intro para aplicar una solución rápida al problema.
Detectar errores
Detectar errores El complemento IntelliJ utiliza el análisis estático para alertarle sobre errores en su código.
SpotBugs se pueden configurar en los ajustes de IntelliJ para que se analice su código. Las reglas que se utilizan realmente se encuentran en la pestaña Detector.
Suelo utilizar SpotBugs después de escribir y revisar mi código. A continuación, ejecuto la opción «Analizar archivos de proyecto, incluidas las fuentes de prueba».
Esto me ayuda a identificar errores, código obsoleto y optimizaciones obvias. También me obliga a investigar algunas de las infracciones notificadas para ayudarme a decidir qué hacer.
SpotBugs detecta problemas, pero no ofrece acciones QuickFix para intentar resolverlos.
SpotBugs es fácil de configurar y lo considero una segunda opinión objetiva y útil que puedo obtener en mi IDE.
Sonar Lint
El complemento Sonar Lint.
SonarLint se puede configurar en los ajustes de IntelliJ para seleccionar las reglas según las cuales se valida el código.
De forma predeterminada, SonarLint se ejecuta en tiempo real y muestra los problemas del código actual que está editando.
SonarLint no ofrece soluciones rápidas, pero la documentación relacionada con los informes de infracciones suele ser clara y estar bien documentada.
En el pasado, SonarLint me ha resultado útil para informarme sobre nuevas funciones de Java que no conocía en las versiones más recientes de Java.
Seguir comprobando
Comprobar el estilo El complemento ofrece una combinación de reglas de formato y calidad del código.
El complemento CheckStyle se suministra en un paquete con «Sun Checks» y «Google Checks».
Las definiciones de estos términos se pueden encontrar fácilmente en Internet.
CheckStyle ofrece el mayor valor añadido cuando un proyecto ha dedicado tiempo a crear su propio conjunto de reglas. Entonces, el complemento IDE se puede configurar para que utilice este conjunto de reglas y los programadores pueden realizar un análisis antes de transferir el código a CI.
CheckStyle se utiliza muy a menudo como complemento de fallo de compilación para procesos de CI cuando el número de infracciones de CheckStyle supera un umbral determinado.
Sensei
Sensei utiliza un análisis estático basado en un árbol sintáctico abstracto (AST) para comparar código y crear QuickFixes. Esto permite identificar de forma muy específica el código que presenta problemas.
El AST permite a QuickFixes, que están asignados a una receta, comprender el código circundante, por ejemplo, cuando se añade una nueva clase al código, cada importación para esta clase se añade solo una vez al archivo fuente y no para cada sustitución.
Sensei desarrollado para facilitar la creación de reglas de coincidencia personalizadas que podrían no existir en otras herramientas o que serían difíciles de configurar.
En lugar de modificar un archivo de configuración, toda la configuración se puede realizar en la interfaz gráfica de usuario. Al crear nuevas recetas, la interfaz gráfica de usuario permite identificar fácilmente a qué código se adapta la receta. Y al definir las soluciones rápidas, se puede comparar inmediatamente el estado del código antes y después. Esto facilita la creación de recetas muy contextuales, es decir, específicas para equipos, tecnologías e incluso programadores individuales.
Utilizo Sensei combinación con otras herramientas de análisis estático, por ejemplo, la mayoría de las herramientas de análisis estático detectan problemas, pero no los solucionan. Un caso de uso frecuente de Sensei Sensei la búsqueda adecuada de la otra herramienta en Sensei y ampliarla con una solución rápida. Esto tiene la ventaja de que la solución personalizada aplicada ya cumple con los estándares de codificación de su proyecto.
Periódicamente creo Sensei que ya están incluidas en el conjunto IntelliJ Intensions, porque el informe Intension no se ajusta del todo al contexto que he creado o porque la solución rápida proporcionada por IntelliJ no se ajusta al patrón de código que quiero utilizar.
Complemento las herramientas existentes, en lugar de intentar sustituirlas por completo.
Sensei también Sensei ser muy útil si identifica una variante contextual de una regla general, por ejemplo, si utiliza una biblioteca SQL que no es compatible con la herramienta de análisis estático, pero las reglas SQL generales del motor de análisis estático siguen siendo válidas, entonces puede utilizar Sensei para crear variantes Sensei de estas reglas.
Sensei no Sensei muchas recetas genéricas como las herramientas de análisis estático mencionadas. Su punto fuerte es que facilita la creación de nuevas recetas, completas con QuickFixes configuradas para adaptarse a su estilo de codificación específico y a sus casos de uso.
NOTA: Estamos trabajando en un archivo público con recetas para cubrir casos de uso genéricos, y lo encontrarás aquí.
Resumen
Tiendo a elegir herramientas que funcionen juntas, sean configurables y 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 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 detectar inmediatamente los problemas de código más frecuentes, a menudo con las soluciones rápidas correspondientes.
- SpotBugs encuentra errores sencillos que quizá se me hayan pasado por alto y me avisa de problemas de rendimiento.
- SonarLint identifica funciones Java que yo desconocía y me pide que modele mi código adicionalmente.
- CheckStyle me ayuda a mantener un estilo de codificación acordado, que también se aplica durante la integración continua.
- Sensei me Sensei a crear QuickFixes para ampliar escenarios comunes que se encuentran con herramientas de análisis estático y a crear recetas específicas para proyectos o tecnologías que son difíciles de configurar en otras herramientas.
---
Instale Sensei IntelliJ con «Preferences\ Plugins» (Mac) o «Settings\ Plugins» (Windows) y, a continuación, busqueSensei Code».
Encontrará un repositorio con código de ejemplo y recetas para casos de uso habituales en la cuenta de GitHub de Secure Code Warrior proyectosensei».
https://github.com/securecodewarrior/sensei-blog-examples
¿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.
Si el análisis se lleva a cabo durante la ejecución del programa, se denomina análisis dinámico.
El análisis estático se utiliza con frecuencia para detectar lo siguiente:
- Brechas 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 consiste en buscar en el código fuente determinados patrones de codificación a los que se asigna una advertencia o información.
Dies könnte so einfach sein wie „JUnit 5-Testklassen müssen nicht 'öffentlich' sein“. Oder etwas, das komplex zu identifizieren ist, wie „Nicht vertrauenswürdige Zeichenketteningabe, die in einer SQL-Ausführungsanweisung verwendet wird“.
Las herramientas de análisis estático difieren en la forma en que implementan esta funcionalidad.
- Tecnología de análisis de código fuente para la creación de un árbol sintáctico abstracto (AST).
- Comparación de texto con expresiones regulares,
- una combinación de lo anterior.
La comparación de expresiones regulares en texto es muy flexible, es fácil escribir reglas para la comparación, pero a menudo puede dar lugar a muchos resultados falsos positivos, y las reglas de comparación no conocen el contexto del código circundante.
El AST-Matching trata el código fuente como código de programa y no solo como archivos llenos de texto. Esto permite una comparación más específica y contextualizada, y puede reducir el número de falsos positivos que se notifican contra el código.
Análisis estático en integración continua
Los análisis estáticos se suelen realizar durante el proceso de integración continua (CI) para generar un informe sobre los problemas de cumplimiento que se puede revisar con el fin de obtener una visión general objetiva de la base de código a lo largo del tiempo.
Algunos usuarios utilizan el análisis estático como medida objetiva de la calidad de su código, configurando la herramienta de análisis estático para que solo se midan determinadas partes del código y solo se informe sobre un subconjunto de reglas.
La objetividad está garantizada por las reglas utilizadas, ya que estas no cambian con el tiempo en su evaluación del código. Es evidente que la combinación de las reglas utilizadas y su configuración es una decisión subjetiva, y diferentes equipos optan por utilizar diferentes reglas en diferentes momentos.
Es útil realizar el análisis estático en CI, pero puede retrasar la retroalimentación al programador. Los programadores no reciben retroalimentación durante la programación, sino más tarde, cuando el código pasa por la herramienta de análisis estático. Otro efecto secundario de la ejecución del análisis estático en CI es que los resultados son más fáciles de ignorar.
Para que los equipos presten más atención a los resultados del análisis estático, normalmente es posible configurar una métrica de umbral en el proceso de compilación, de modo que la compilación falle si se supera la métrica, por ejemplo, una serie de reglas activadas.
Análisis estático en el IDE
Para obtener comentarios más rápidamente, existen muchos complementos IDE que ejecutan las reglas del análisis estático en el IDE cuando es necesario o a intervalos regulares, cuando cambia el código.
Las infracciones de las reglas pueden mostrarse en el IDE mientras el programador escribe el código. Para dificultar el incumplimiento de las reglas, las infracciones a menudo pueden configurarse para que se muestren en el editor como código subrayado.
Personalmente, creo que es un método útil para mejorar mi código, especialmente cuando trabajo con una nueva biblioteca cubierta por la herramienta de análisis estático. Sin embargo, puede resultar «ruidoso» en caso de falsos positivos o reglas que no le interesen. No obstante, esto se soluciona dando un paso adicional para configurar la herramienta de análisis estático de modo que se ignoren determinadas reglas.
Corrección de código basada en reglas de análisis estático
En la mayoría de las herramientas de análisis estático, la corrección de la regla queda a cargo del programador, por lo que este debe comprender la causa de la infracción de la regla y saber cómo solucionarla.
Muy pocas herramientas de análisis estático ofrecen también la posibilidad de corregir las infracciones, ya que la corrección suele depender del equipo, la tecnología utilizada y los estilos de codificación acordados.
Reglas estándar
Se puede generar una confianza errónea en la calidad de las reglas cuando las herramientas de análisis estático están equipadas con reglas estándar. Es tentador creer que cubren todos los problemas con los que podría encontrarse un programador y todas las circunstancias en las que debería aplicarse la regla. A veces, las circunstancias en las que debería aplicarse una regla son sutiles y pueden no ser fáciles de detectar.
Existe la esperanza de que, mediante el uso de una herramienta de análisis estático y un examen más detallado de las reglas y las infracciones, los programadores desarrollen la capacidad de reconocer y evitar el problema en el contexto de su dominio específico.
Si el dominio requiere reglas de contexto, es posible que las herramientas de análisis estático no dispongan de reglas que se ajusten a su dominio o biblioteca y, además, estas herramientas suelen ser difíciles de configurar y ampliar.
Molestias
Ninguno de estos «molestias» es insuperable:
- falso positivo
- Falta de correcciones
- Configuración para ignorar reglas
- Añadir reglas específicas del contexto
Sin embargo, a menudo se utilizan como excusas para evitar desde el principio el uso de herramientas de análisis estático, lo cual es una lástima, ya que el uso del análisis estático puede ser extremadamente útil para:
- Destacar mejores enfoques para los desarrolladores jóvenes.
- Reciba comentarios rápidos sobre infracciones claras de codificación.
- Identifique problemas oscuros con los que el programador nunca se ha encontrado.
- Confirmar que el programador ha elegido un buen enfoque de codificación (siempre que no se hayan notificado infracciones).
Herramientas de análisis estático basadas en IDE
Como colaborador individual en un proyecto, me gusta utilizar herramientas de análisis estático que se ejecutan en el IDE, lo que me permite obtener una respuesta rápida 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 encontrar herramientas que me proporcionen una ventaja y mejoren mi flujo de trabajo individual.
Cuando las herramientas se ejecutan en el IDE, puede resultar tentador considerarlas sinónimos, ya que suelen utilizar la misma interfaz gráfica de usuario básica y el mismo enfoque de configuración.
Las herramientas pueden tener funciones o conjuntos de reglas que se superponen, pero para obtener el máximo beneficio, instalo varias herramientas para aprovechar sus puntos fuertes.
Las herramientas IDE para análisis estáticos que utilizo activamente al programar se enumeran a continuación:
- Las inspecciones integradas de IntelliJ: patrones de codificación habituales
- SpotBugs — errores frecuentes
- SonarLint: patrones generales de uso
- CheckStyle: patrones de estilo habituales
- Sensei Secure Code Warrior creación de reglas personalizadas
Las utilizo todas porque funcionan bien juntas, se complementan y se complementan entre sí.
Inspecciones de IntelliJ
Si utiliza IntelliJ, ya está utilizando sus inspecciones.
Estas son reglas para análisis estáticos que se marcan en el IDE. Algunas de ellas también disponen de opciones QuickFix con las que se puede reescribir el código para solucionar el problema.
Las reglas se pueden activar y desactivar, y puede seleccionar el nivel de error con el que se resaltan en el IDE.
Hay muchas inspecciones buenas en IntelliJ. Lo sé porque las he leído mientras escribo esto. Utilizo las inspecciones de IntelliJ como valores predeterminados y no las he configurado, pero para sacar el máximo partido a las inspecciones, debe leerlas, identificar las que son relevantes para su estilo de codificación y configurar el nivel de advertencia para que las note en el código.
Lo mejor de las inspecciones de IntelliJ es que están incluidas de forma gratuita en el IDE y ayudan a desarrollar la memoria muscular de:
- Detección de advertencias y errores en el código fuente mientras se escribe el código.
- Mueva el puntero del ratón sobre el código marcado para conocer las infracciones de las normas.
- Utilice Alt+Intro para aplicar una solución rápida al problema.
Detectar errores
Detectar errores El complemento IntelliJ utiliza el análisis estático para alertarle sobre errores en su código.
SpotBugs se pueden configurar en los ajustes de IntelliJ para que se analice su código. Las reglas que se utilizan realmente se encuentran en la pestaña Detector.
Suelo utilizar SpotBugs después de escribir y revisar mi código. A continuación, ejecuto la opción «Analizar archivos de proyecto, incluidas las fuentes de prueba».
Esto me ayuda a identificar errores, código obsoleto y optimizaciones obvias. También me obliga a investigar algunas de las infracciones notificadas para ayudarme a decidir qué hacer.
SpotBugs detecta problemas, pero no ofrece acciones QuickFix para intentar resolverlos.
SpotBugs es fácil de configurar y lo considero una segunda opinión objetiva y útil que puedo obtener en mi IDE.
Sonar Lint
El complemento Sonar Lint.
SonarLint se puede configurar en los ajustes de IntelliJ para seleccionar las reglas según las cuales se valida el código.
De forma predeterminada, SonarLint se ejecuta en tiempo real y muestra los problemas del código actual que está editando.
SonarLint no ofrece soluciones rápidas, pero la documentación relacionada con los informes de infracciones suele ser clara y estar bien documentada.
En el pasado, SonarLint me ha resultado útil para informarme sobre nuevas funciones de Java que no conocía en las versiones más recientes de Java.
Seguir comprobando
Comprobar el estilo El complemento ofrece una combinación de reglas de formato y calidad del código.
El complemento CheckStyle se suministra en un paquete con «Sun Checks» y «Google Checks».
Las definiciones de estos términos se pueden encontrar fácilmente en Internet.
CheckStyle ofrece el mayor valor añadido cuando un proyecto ha dedicado tiempo a crear su propio conjunto de reglas. Entonces, el complemento IDE se puede configurar para que utilice este conjunto de reglas y los programadores pueden realizar un análisis antes de transferir el código a CI.
CheckStyle se utiliza muy a menudo como complemento de fallo de compilación para procesos de CI cuando el número de infracciones de CheckStyle supera un umbral determinado.
Sensei
Sensei utiliza un análisis estático basado en un árbol sintáctico abstracto (AST) para comparar código y crear QuickFixes. Esto permite identificar de forma muy específica el código que presenta problemas.
El AST permite a QuickFixes, que están asignados a una receta, comprender el código circundante, por ejemplo, cuando se añade una nueva clase al código, cada importación para esta clase se añade solo una vez al archivo fuente y no para cada sustitución.
Sensei desarrollado para facilitar la creación de reglas de coincidencia personalizadas que podrían no existir en otras herramientas o que serían difíciles de configurar.
En lugar de modificar un archivo de configuración, toda la configuración se puede realizar en la interfaz gráfica de usuario. Al crear nuevas recetas, la interfaz gráfica de usuario permite identificar fácilmente a qué código se adapta la receta. Y al definir las soluciones rápidas, se puede comparar inmediatamente el estado del código antes y después. Esto facilita la creación de recetas muy contextuales, es decir, específicas para equipos, tecnologías e incluso programadores individuales.
Utilizo Sensei combinación con otras herramientas de análisis estático, por ejemplo, la mayoría de las herramientas de análisis estático detectan problemas, pero no los solucionan. Un caso de uso frecuente de Sensei Sensei la búsqueda adecuada de la otra herramienta en Sensei y ampliarla con una solución rápida. Esto tiene la ventaja de que la solución personalizada aplicada ya cumple con los estándares de codificación de su proyecto.
Periódicamente creo Sensei que ya están incluidas en el conjunto IntelliJ Intensions, porque el informe Intension no se ajusta del todo al contexto que he creado o porque la solución rápida proporcionada por IntelliJ no se ajusta al patrón de código que quiero utilizar.
Complemento las herramientas existentes, en lugar de intentar sustituirlas por completo.
Sensei también Sensei ser muy útil si identifica una variante contextual de una regla general, por ejemplo, si utiliza una biblioteca SQL que no es compatible con la herramienta de análisis estático, pero las reglas SQL generales del motor de análisis estático siguen siendo válidas, entonces puede utilizar Sensei para crear variantes Sensei de estas reglas.
Sensei no Sensei muchas recetas genéricas como las herramientas de análisis estático mencionadas. Su punto fuerte es que facilita la creación de nuevas recetas, completas con QuickFixes configuradas para adaptarse a su estilo de codificación específico y a sus casos de uso.
NOTA: Estamos trabajando en un archivo público con recetas para cubrir casos de uso genéricos, y lo encontrarás aquí.
Resumen
Tiendo a elegir herramientas que funcionen juntas, sean configurables y 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 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 detectar inmediatamente los problemas de código más frecuentes, a menudo con las soluciones rápidas correspondientes.
- SpotBugs encuentra errores sencillos que quizá se me hayan pasado por alto y me avisa de problemas de rendimiento.
- SonarLint identifica funciones Java que yo desconocía y me pide que modele mi código adicionalmente.
- CheckStyle me ayuda a mantener un estilo de codificación acordado, que también se aplica durante la integración continua.
- Sensei me Sensei a crear QuickFixes para ampliar escenarios comunes que se encuentran con herramientas de análisis estático y a crear recetas específicas para proyectos o tecnologías que son difíciles de configurar en otras herramientas.
---
Instale Sensei IntelliJ con «Preferences\ Plugins» (Mac) o «Settings\ Plugins» (Windows) y, a continuación, busqueSensei Code».
Encontrará un repositorio con código de ejemplo y recetas para casos de uso habituales en la cuenta de GitHub de Secure Code Warrior proyectosensei».
https://github.com/securecodewarrior/sensei-blog-examples
Haga clic en el enlace de abajo y descargue el PDF de este recurso.
Secure Code Warrior a disposición de su empresa para ayudarle a proteger el código durante todo el ciclo de desarrollo de software y crear una cultura en la que la ciberseguridad sea una prioridad. Tanto si es responsable de seguridad de aplicaciones, desarrollador, responsable de seguridad de la información o cualquier otra persona relacionada con la seguridad, podemos ayudar a su empresa a reducir los riesgos asociados al código inseguro.
Ver informeReservar una demostración
Alan Richardson cuenta con más de veinte años de experiencia profesional en TI, trabajando como desarrollador y en todos los niveles de la jerarquía de pruebas, desde probador hasta jefe de pruebas. Jefe de Relaciones con los Desarrolladores en Secure Code Warrior, trabaja directamente con los equipos, para mejorar el desarrollo de un código seguro de calidad. Alan es autor de cuatro libros, entre ellos "Dear Evil Tester" y "Java For Testers". Alan también ha creado una formación en línea courses para ayudar a la gente a aprender las pruebas técnicas de la web y Selenium WebDriver con Java. Alan publica sus escritos y vídeos de formación en SeleniumSimplified.com, EvilTester.com, JavaForTesters.com, y CompendiumDev.co.uk.
¿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.
Si el análisis se lleva a cabo durante la ejecución del programa, se denomina análisis dinámico.
El análisis estático se utiliza con frecuencia para detectar lo siguiente:
- Brechas 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 consiste en buscar en el código fuente determinados patrones de codificación a los que se asigna una advertencia o información.
Dies könnte so einfach sein wie „JUnit 5-Testklassen müssen nicht 'öffentlich' sein“. Oder etwas, das komplex zu identifizieren ist, wie „Nicht vertrauenswürdige Zeichenketteningabe, die in einer SQL-Ausführungsanweisung verwendet wird“.
Las herramientas de análisis estático difieren en la forma en que implementan esta funcionalidad.
- Tecnología de análisis de código fuente para la creación de un árbol sintáctico abstracto (AST).
- Comparación de texto con expresiones regulares,
- una combinación de lo anterior.
La comparación de expresiones regulares en texto es muy flexible, es fácil escribir reglas para la comparación, pero a menudo puede dar lugar a muchos resultados falsos positivos, y las reglas de comparación no conocen el contexto del código circundante.
El AST-Matching trata el código fuente como código de programa y no solo como archivos llenos de texto. Esto permite una comparación más específica y contextualizada, y puede reducir el número de falsos positivos que se notifican contra el código.
Análisis estático en integración continua
Los análisis estáticos se suelen realizar durante el proceso de integración continua (CI) para generar un informe sobre los problemas de cumplimiento que se puede revisar con el fin de obtener una visión general objetiva de la base de código a lo largo del tiempo.
Algunos usuarios utilizan el análisis estático como medida objetiva de la calidad de su código, configurando la herramienta de análisis estático para que solo se midan determinadas partes del código y solo se informe sobre un subconjunto de reglas.
La objetividad está garantizada por las reglas utilizadas, ya que estas no cambian con el tiempo en su evaluación del código. Es evidente que la combinación de las reglas utilizadas y su configuración es una decisión subjetiva, y diferentes equipos optan por utilizar diferentes reglas en diferentes momentos.
Es útil realizar el análisis estático en CI, pero puede retrasar la retroalimentación al programador. Los programadores no reciben retroalimentación durante la programación, sino más tarde, cuando el código pasa por la herramienta de análisis estático. Otro efecto secundario de la ejecución del análisis estático en CI es que los resultados son más fáciles de ignorar.
Para que los equipos presten más atención a los resultados del análisis estático, normalmente es posible configurar una métrica de umbral en el proceso de compilación, de modo que la compilación falle si se supera la métrica, por ejemplo, una serie de reglas activadas.
Análisis estático en el IDE
Para obtener comentarios más rápidamente, existen muchos complementos IDE que ejecutan las reglas del análisis estático en el IDE cuando es necesario o a intervalos regulares, cuando cambia el código.
Las infracciones de las reglas pueden mostrarse en el IDE mientras el programador escribe el código. Para dificultar el incumplimiento de las reglas, las infracciones a menudo pueden configurarse para que se muestren en el editor como código subrayado.
Personalmente, creo que es un método útil para mejorar mi código, especialmente cuando trabajo con una nueva biblioteca cubierta por la herramienta de análisis estático. Sin embargo, puede resultar «ruidoso» en caso de falsos positivos o reglas que no le interesen. No obstante, esto se soluciona dando un paso adicional para configurar la herramienta de análisis estático de modo que se ignoren determinadas reglas.
Corrección de código basada en reglas de análisis estático
En la mayoría de las herramientas de análisis estático, la corrección de la regla queda a cargo del programador, por lo que este debe comprender la causa de la infracción de la regla y saber cómo solucionarla.
Muy pocas herramientas de análisis estático ofrecen también la posibilidad de corregir las infracciones, ya que la corrección suele depender del equipo, la tecnología utilizada y los estilos de codificación acordados.
Reglas estándar
Se puede generar una confianza errónea en la calidad de las reglas cuando las herramientas de análisis estático están equipadas con reglas estándar. Es tentador creer que cubren todos los problemas con los que podría encontrarse un programador y todas las circunstancias en las que debería aplicarse la regla. A veces, las circunstancias en las que debería aplicarse una regla son sutiles y pueden no ser fáciles de detectar.
Existe la esperanza de que, mediante el uso de una herramienta de análisis estático y un examen más detallado de las reglas y las infracciones, los programadores desarrollen la capacidad de reconocer y evitar el problema en el contexto de su dominio específico.
Si el dominio requiere reglas de contexto, es posible que las herramientas de análisis estático no dispongan de reglas que se ajusten a su dominio o biblioteca y, además, estas herramientas suelen ser difíciles de configurar y ampliar.
Molestias
Ninguno de estos «molestias» es insuperable:
- falso positivo
- Falta de correcciones
- Configuración para ignorar reglas
- Añadir reglas específicas del contexto
Sin embargo, a menudo se utilizan como excusas para evitar desde el principio el uso de herramientas de análisis estático, lo cual es una lástima, ya que el uso del análisis estático puede ser extremadamente útil para:
- Destacar mejores enfoques para los desarrolladores jóvenes.
- Reciba comentarios rápidos sobre infracciones claras de codificación.
- Identifique problemas oscuros con los que el programador nunca se ha encontrado.
- Confirmar que el programador ha elegido un buen enfoque de codificación (siempre que no se hayan notificado infracciones).
Herramientas de análisis estático basadas en IDE
Como colaborador individual en un proyecto, me gusta utilizar herramientas de análisis estático que se ejecutan en el IDE, lo que me permite obtener una respuesta rápida 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 encontrar herramientas que me proporcionen una ventaja y mejoren mi flujo de trabajo individual.
Cuando las herramientas se ejecutan en el IDE, puede resultar tentador considerarlas sinónimos, ya que suelen utilizar la misma interfaz gráfica de usuario básica y el mismo enfoque de configuración.
Las herramientas pueden tener funciones o conjuntos de reglas que se superponen, pero para obtener el máximo beneficio, instalo varias herramientas para aprovechar sus puntos fuertes.
Las herramientas IDE para análisis estáticos que utilizo activamente al programar se enumeran a continuación:
- Las inspecciones integradas de IntelliJ: patrones de codificación habituales
- SpotBugs — errores frecuentes
- SonarLint: patrones generales de uso
- CheckStyle: patrones de estilo habituales
- Sensei Secure Code Warrior creación de reglas personalizadas
Las utilizo todas porque funcionan bien juntas, se complementan y se complementan entre sí.
Inspecciones de IntelliJ
Si utiliza IntelliJ, ya está utilizando sus inspecciones.
Estas son reglas para análisis estáticos que se marcan en el IDE. Algunas de ellas también disponen de opciones QuickFix con las que se puede reescribir el código para solucionar el problema.
Las reglas se pueden activar y desactivar, y puede seleccionar el nivel de error con el que se resaltan en el IDE.
Hay muchas inspecciones buenas en IntelliJ. Lo sé porque las he leído mientras escribo esto. Utilizo las inspecciones de IntelliJ como valores predeterminados y no las he configurado, pero para sacar el máximo partido a las inspecciones, debe leerlas, identificar las que son relevantes para su estilo de codificación y configurar el nivel de advertencia para que las note en el código.
Lo mejor de las inspecciones de IntelliJ es que están incluidas de forma gratuita en el IDE y ayudan a desarrollar la memoria muscular de:
- Detección de advertencias y errores en el código fuente mientras se escribe el código.
- Mueva el puntero del ratón sobre el código marcado para conocer las infracciones de las normas.
- Utilice Alt+Intro para aplicar una solución rápida al problema.
Detectar errores
Detectar errores El complemento IntelliJ utiliza el análisis estático para alertarle sobre errores en su código.
SpotBugs se pueden configurar en los ajustes de IntelliJ para que se analice su código. Las reglas que se utilizan realmente se encuentran en la pestaña Detector.
Suelo utilizar SpotBugs después de escribir y revisar mi código. A continuación, ejecuto la opción «Analizar archivos de proyecto, incluidas las fuentes de prueba».
Esto me ayuda a identificar errores, código obsoleto y optimizaciones obvias. También me obliga a investigar algunas de las infracciones notificadas para ayudarme a decidir qué hacer.
SpotBugs detecta problemas, pero no ofrece acciones QuickFix para intentar resolverlos.
SpotBugs es fácil de configurar y lo considero una segunda opinión objetiva y útil que puedo obtener en mi IDE.
Sonar Lint
El complemento Sonar Lint.
SonarLint se puede configurar en los ajustes de IntelliJ para seleccionar las reglas según las cuales se valida el código.
De forma predeterminada, SonarLint se ejecuta en tiempo real y muestra los problemas del código actual que está editando.
SonarLint no ofrece soluciones rápidas, pero la documentación relacionada con los informes de infracciones suele ser clara y estar bien documentada.
En el pasado, SonarLint me ha resultado útil para informarme sobre nuevas funciones de Java que no conocía en las versiones más recientes de Java.
Seguir comprobando
Comprobar el estilo El complemento ofrece una combinación de reglas de formato y calidad del código.
El complemento CheckStyle se suministra en un paquete con «Sun Checks» y «Google Checks».
Las definiciones de estos términos se pueden encontrar fácilmente en Internet.
CheckStyle ofrece el mayor valor añadido cuando un proyecto ha dedicado tiempo a crear su propio conjunto de reglas. Entonces, el complemento IDE se puede configurar para que utilice este conjunto de reglas y los programadores pueden realizar un análisis antes de transferir el código a CI.
CheckStyle se utiliza muy a menudo como complemento de fallo de compilación para procesos de CI cuando el número de infracciones de CheckStyle supera un umbral determinado.
Sensei
Sensei utiliza un análisis estático basado en un árbol sintáctico abstracto (AST) para comparar código y crear QuickFixes. Esto permite identificar de forma muy específica el código que presenta problemas.
El AST permite a QuickFixes, que están asignados a una receta, comprender el código circundante, por ejemplo, cuando se añade una nueva clase al código, cada importación para esta clase se añade solo una vez al archivo fuente y no para cada sustitución.
Sensei desarrollado para facilitar la creación de reglas de coincidencia personalizadas que podrían no existir en otras herramientas o que serían difíciles de configurar.
En lugar de modificar un archivo de configuración, toda la configuración se puede realizar en la interfaz gráfica de usuario. Al crear nuevas recetas, la interfaz gráfica de usuario permite identificar fácilmente a qué código se adapta la receta. Y al definir las soluciones rápidas, se puede comparar inmediatamente el estado del código antes y después. Esto facilita la creación de recetas muy contextuales, es decir, específicas para equipos, tecnologías e incluso programadores individuales.
Utilizo Sensei combinación con otras herramientas de análisis estático, por ejemplo, la mayoría de las herramientas de análisis estático detectan problemas, pero no los solucionan. Un caso de uso frecuente de Sensei Sensei la búsqueda adecuada de la otra herramienta en Sensei y ampliarla con una solución rápida. Esto tiene la ventaja de que la solución personalizada aplicada ya cumple con los estándares de codificación de su proyecto.
Periódicamente creo Sensei que ya están incluidas en el conjunto IntelliJ Intensions, porque el informe Intension no se ajusta del todo al contexto que he creado o porque la solución rápida proporcionada por IntelliJ no se ajusta al patrón de código que quiero utilizar.
Complemento las herramientas existentes, en lugar de intentar sustituirlas por completo.
Sensei también Sensei ser muy útil si identifica una variante contextual de una regla general, por ejemplo, si utiliza una biblioteca SQL que no es compatible con la herramienta de análisis estático, pero las reglas SQL generales del motor de análisis estático siguen siendo válidas, entonces puede utilizar Sensei para crear variantes Sensei de estas reglas.
Sensei no Sensei muchas recetas genéricas como las herramientas de análisis estático mencionadas. Su punto fuerte es que facilita la creación de nuevas recetas, completas con QuickFixes configuradas para adaptarse a su estilo de codificación específico y a sus casos de uso.
NOTA: Estamos trabajando en un archivo público con recetas para cubrir casos de uso genéricos, y lo encontrarás aquí.
Resumen
Tiendo a elegir herramientas que funcionen juntas, sean configurables y 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 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 detectar inmediatamente los problemas de código más frecuentes, a menudo con las soluciones rápidas correspondientes.
- SpotBugs encuentra errores sencillos que quizá se me hayan pasado por alto y me avisa de problemas de rendimiento.
- SonarLint identifica funciones Java que yo desconocía y me pide que modele mi código adicionalmente.
- CheckStyle me ayuda a mantener un estilo de codificación acordado, que también se aplica durante la integración continua.
- Sensei me Sensei a crear QuickFixes para ampliar escenarios comunes que se encuentran con herramientas de análisis estático y a crear recetas específicas para proyectos o tecnologías que son difíciles de configurar en otras herramientas.
---
Instale Sensei IntelliJ con «Preferences\ Plugins» (Mac) o «Settings\ Plugins» (Windows) y, a continuación, busqueSensei Code».
Encontrará un repositorio con código de ejemplo y recetas para casos de uso habituales en la cuenta de GitHub de Secure Code Warrior proyectosensei».
https://github.com/securecodewarrior/sensei-blog-examples
Índice
Alan Richardson cuenta con más de veinte años de experiencia profesional en TI, trabajando como desarrollador y en todos los niveles de la jerarquía de pruebas, desde probador hasta jefe de pruebas. Jefe de Relaciones con los Desarrolladores en Secure Code Warrior, trabaja directamente con los equipos, para mejorar el desarrollo de un código seguro de calidad. Alan es autor de cuatro libros, entre ellos "Dear Evil Tester" y "Java For Testers". Alan también ha creado una formación en línea courses para ayudar a la gente a aprender las pruebas técnicas de la web y Selenium WebDriver con Java. Alan publica sus escritos y vídeos de formación en SeleniumSimplified.com, EvilTester.com, JavaForTesters.com, y CompendiumDev.co.uk.
Secure Code Warrior a disposición de su empresa para ayudarle a proteger el código durante todo el ciclo de desarrollo de software y crear una cultura en la que la ciberseguridad sea una prioridad. Tanto si es responsable de seguridad de aplicaciones, desarrollador, responsable de seguridad de la información o cualquier otra persona relacionada con la seguridad, podemos ayudar a su empresa a reducir los riesgos asociados al código inseguro.
Reservar una demostraciónDescargarRecursos para empezar
Temas y contenidos de la formación Securecode
Nuestros contenidos líderes en el sector se desarrollan continuamente para adaptarse al cambiante panorama del desarrollo de software, teniendo en cuenta su función. Temas que abarcan desde la inteligencia artificial hasta la inyección XQuery y que se ofrecen para una amplia variedad de funciones, desde arquitectos e ingenieros hasta gestores de productos y control de calidad. Eche un vistazo a nuestro catálogo de contenidos por temas y funciones.
La Cámara de Comercio establece el estándar para la seguridad impulsada por desarrolladores a gran escala
Kamer van Koophandel comparte cómo ha integrado la codificación segura en el desarrollo diario mediante certificaciones basadas en roles, evaluaciones comparativas de Trust Score y una cultura de responsabilidad compartida en materia de seguridad.
%20(1).avif)
.avif)
Modelado de amenazas con IA: convertir a cada desarrollador en un modelador de amenazas
Saldrá mejor equipado para ayudar a los desarrolladores a combinar ideas y técnicas de modelado de amenazas con las herramientas de IA que ya utilizan para reforzar la seguridad, mejorar la colaboración y crear software más resistente desde el principio.
Recursos para empezar
Cybermon ha vuelto: ¡Derrota al jefe! Las misiones KI ya están disponibles bajo demanda.
Cybermon 2025 Beat the Boss ya está disponible durante todo el año en SCW. Utiliza requisitos de seguridad avanzados de IA/LLM para reforzar el desarrollo seguro de la IA a gran escala.
Explicación de la Ley de Resiliencia Cibernética: qué significa para el desarrollo de software Secure by Design
Descubra qué exige la Ley de Ciberresiliencia de la UE (CRA), a quién se aplica y cómo los equipos de desarrollo pueden prepararse para ella mediante métodos seguros, la prevención de vulnerabilidades de seguridad y el desarrollo de capacidades para los desarrolladores.
Facilitador 1: Criterios de éxito definidos y medibles
El facilitador 1 abre nuestra serie de diez partes titulada «Facilitadores del éxito» y muestra cómo la codificación segura puede combinarse con resultados empresariales como la reducción de riesgos y la velocidad para lograr la madurez del programa a largo plazo.
