¿Cómo auditar un proyecto de Java EE?

Question

Tengo que auditar la calidad de la arquitectura del código y la capacidad de mantenimiento (al final para estar seguro de que tenemos lo que pagamos) un proyecto web Java EE basado en JSF/CDI/EJB3.0/JPA (solo para nombrar algunos de las tecnologías involucradas).

Puede que este no sea el lugar adecuado para preguntar, pero ¿cómo se maneja este tipo de tareas? Básicamente, pasaría de grano grueso a grano fino, es decir, de toda la arquitectura al código java. ¿Es mejor tratar con cada capa por completo? ¿Debo pasar más tiempo en las capas de bajo nivel?

¿Evalúa todo (construcción, implementación, prueba)?

Answer 1

En el nivel físico/de implementación más bajo, lo que me gusta hacer es adoptar maven como una herramienta de compilación, y luego configurar los extensos informes de maven, para producir un sitio web lleno de varias métricas de código.

• Para empezar no es el maven checkstyle plugin que puede informar sobre la conformidad de código a un nivel especificado, la coherencia de las normas de codificación tiene muchas ventajas obvias, la mayoría de los proyectos serían simplemente adoptar una de las normas pre-configurados, por ejemplo, sol o apache.
• Los findbugs plugin enumera los posibles errores de programación
• Hay una selección de informes de cobertura de código, he utilizado cobertura. Muestran línea por línea en una aplicación cuyas piezas están cubiertas por pruebas unitarias. Maven admite pruebas unitarias en el ciclo de vida de compilación, ejecutándolas como parte de la compilación. Esto me ha salvado un par de veces.
• El PMD plugin identifica el código duplicado y resalta las áreas que pueden necesitar refactorización.

Una vez que esto se configura y se convierte en parte del ciclo de construcción normal, básicamente se ocupa de sí mismo, y usted no tendrá que preocuparse por hacer grandes auditorías/actualizaciones bianuales.

Muchos de los informes tienen límites de umbral que se pueden configurar para fallar la construcción si se infringen, es decir, más de n% de errores de estilo de comprobación, provocan un error de compilación.

Maven también promueve un enfoque modular para crear aplicaciones, esto da como resultado módulos más pequeños comprensibles y reutilizables, así como la separación de preocupaciones, es decir, módulos separados para capas de presentación y persistencia. El principal beneficio que proporciona maven es gestionar las interdependencias entre los módulos.

Esto no le ayuda mucho en las capas de arquitectura de nivel superior, por lo que se necesitará un enfoque complementario para cubrir esa dimensión.

Vea algunos ejemplos de informes en este enlace
http://maven.apache.org/plugins/maven-dependency-plugin/project-reports.html

Answer 2

para ayudar en la auditoría a nivel de código y probablemente en la salud del proyecto también un software que puede ayudarle es Sónar ... es muy simple de instalar sólo algunos comandos de Maven , viene con una gran cantidad de estándares de código probados como calidad de código, reutilización, mediciones de malas prácticas, etc.

Ejecuta en su proyecto SVN o CVS y genera un sitio web con gráficos que representan el estado pasado y actual de las métricas está creando, por lo que puede navegar por los datos del proyecto y realizar un seguimiento de las mejoras o fallas.

También utiliza todos esos experto y Maven plugins enumerados en la otra respuesta como Cobertura, encontrar errores etc ...

http://www.sonarsource.org/

sólo tiene que descargar y punto a la de Repo.

Answer 3

Además de las métricas de código de nivel inferior y el análisis estático ya mencionados, agregaría una herramienta como Structure101 para ayudar a analizar estructuras y dependencias de más alto nivel. También puede ayudar a refactorizar lo mismo.

La identificación de conglomerados de dependencias puede ayudar a determinar si la aplicación fue escrita teniendo en mente la separación de preocupaciones y la modularidad, y puede ayudar a identificar posibles puntos conflictivos al considerar la extensión o modificación.

Answer 4

Asegúrese de dividirlo en áreas de interés y abordarlas individualmente. Áreas que se me ocurren a considerar son:

1. de conformidad con los requisitos especificados (esperemos que éstos son específicos)
2. rendimiento/escalabilidad
3. calidad de código (incluidos los convenios que desea seguir)
4. Cobertura de la prueba
5. Licencias de complemento/biblioteca

Parece que otros han tratado los elementos 3 y 4. Dado que estás preguntando la misión Ahora (presumiblemente después de haber recibido el producto) 1 y 2 probablemente tendrán que ser procesos manuales a menos que tenga pruebas de funcionalidad automatizadas ya escritas (o quiera automatizar las pruebas para que pueda verificar las versiones futuras de lo que compró). 5 es un elemento que a veces se pasa por alto, pero puede ser MUY importante. Probablemente no quiera que el código GPL se enganche si va a revender este software. Debe revisar las licencias de cada biblioteca incluida y decidir cuáles son compatibles con sus objetivos.

Answer 5

Para comprender su arquitectura, puede probar JavaDepend ofrece la posibilidad de consultar código con CQL, como SQL para bases de datos, con más de 82 métricas y muchas vistas interactivas para profundizar en su diseño, arquitectura e implementación.