Preguntas para determinar el conocimiento de Maven

Question

Solicité formación de Maven en el trabajo, y los jefes quieren contratar a alguien que conozca a Maven para que trabaje con nosotros como consultor para que aprendamos Maven desde una perspectiva real en lugar de una formación perspectiva.

Me han encomendado la tarea de plantearme preguntas de diversas dificultades para solicitar contrataciones potenciales a fin de determinar su capacidad de Maven. El problema es que todavía no entiendo completamente a Maven (de ahí la solicitud de capacitación).

¿Qué preguntas le pedirías a alguien para determinar su habilidad Maven, y qué nivel de conocimiento tendría alguien de Maven para responderlas?

Answer 1

En mi opinión, un "consultor Maven" debe:

• Tener una buena comprensión de cómo Maven se diferencia de otras herramientas de construcción como Ant (Maven proporciona una "lengua franca" para la gestión de proyectos).
• Comprenda bien los principios de Maven: Convenciones sobre la configuración, el diseño predeterminado, las convenciones de nomenclatura, la filosofía de la herramienta (una salida principal por proyecto).
• Conozca bien cómo funciona Maven: de dónde vienen las convenciones (el super POM), los ciclos de vida (principal, limpio, sitio), las fases, cómo los complementos están ligados a las fases, la influencia del embalaje, etc.
• Conozca qué son los perfiles y cómo se pueden usar para tratar con diferentes entornos, cómo activarlos.
• Sepa cómo usar complementos, cómo configurarlos, cómo enchufarlos en una estructura Maven.
• Conozca cómo funcionan los repositorios, la diferencia entre repositorios locales y remotos, qué son las dependencias de SNAPSHOT.
• Conozca cómo se resuelven las dependencias, qué dependencias transitivas hay, cómo controlarlas, qué ámbito de dependencias hay, cómo usar dependencyManagement.
• Sepa cómo implementar controles de estado de código, los complementos esenciales (Checkstyle, PMD y complementos Findbugs), cómo implementar varios tipos de pruebas (unidad, integración, funcional), cómo medir la cobertura, cuándo fallar la compilación, cuándo para reportar.
• Sepa cómo configurar maven en un entorno corporativo (utilizando un repositorio compartido, configurando CI, un POM de la compañía).
• Conozca cómo manejar escenarios avanzados de empaque (con el complemento de ensamblaje)
• Conozca cómo manejar la implementación, los diversos protocolos, el complemento de implementación, el complemento de lanzamiento, la resolución SNAPSHOT.
• Sepa cómo configurar una compilación Maven para un proyecto Java EE, cómo configurar una compilación de varios módulos, qué módulos se requieren, cómo probar en el entorno de desarrollo, cómo manejar el entorno de producción.

Alguien con estas habilidades debe ponerlo en el camino correcto (y es muy probable que tenga una experiencia decente de Maven).

Answer 2

Le sugiero que piense en lo que quiere hacer con Maven, o por qué quiere introducirlo en sus proyectos. Tal vez le pregunte a su jefe por sus motivos al presentar Maven.

Después de haber nombrado sus objetivos principales por qué para presentar Maven. Pregunte a posibles consultores cómo usarían Maven para lograr esos objetivos.

Ejemplos 1
Objetivo: Mejorar la calidad del código general de proyecto.

Pregunta: ¿Cómo podemos usar Maven para mejorar la calidad general de nuestro código en los proyectos?

Respuesta posible: Maven tiene varios plug-ins para forzar la calidad del código/meassure en proyectos, podríamos integrar a las personas en nuestras buildscripts en casi ningún momento. (Por ejemplo checkstlye, PMD, Cobertura, xradar ...)

Ejemplos 2
Objetivo: La creación de scripts de despliegue automatizado por varios entornos de destino.

Pregunta: ¿Cómo podemos utilizar Maven para desplegar automáticamente artefactos en varios entornos de destino.

Posible respuesta: Podríamos usar los complementos de Maven para el despliegue (por ejemplo, Cargo) y usar los perfiles de maven para manejar varias configuraciones.

a.s.o.

Answer 3

Estas son las preguntas que me gustaría preguntar:

• ¿Cómo hacer cumplir el uso de JDK6 para un grupo de proyectos?
• ¿Cómo harías cumplir el uso de una versión particular de los complementos ?
• ¿Cuáles son algunas de las razones por las que utilizaría un ensamblado para construir un contenedor en lugar del plugin jar?
• Describa el proceso de publicación de un proyecto de Java EE compuesto por un EJB, un archivo WAR y dos jar de utilidad.
• ¿Cuántos repositorios debe tener un servidor de repositorio interno de compañía y por qué?
• ¿Cómo estructuraría un proyecto POM compuesto por N proyectos de niños para que pueda ser utilizado fácilmente en Eclipse?

Todas estas preguntas tienen al menos dos respuestas. Estaría buscando a alguien que pueda brindar al menos dos respuestas y señalar los pros y los contras de cada enfoque. Idealmente, esta persona debería ajustar la configuración para que sea menos perjudicial para la forma en que su entorno ya funciona.

Answer 4

le pediría:

• describir lo que es la práctica de SMC?
• Describa su infraestructura Maven ideal (servidor, repositorios, CI, complementos, convenciones, etc.)?

Ambas son preguntas muy abiertas, pero deben darle una idea de sus habilidades y lo que puede aprender de él y lo que podría aportar a su empresa.

EDITAR

Maven es sólo una parte de la estrategia general de gestión de configuración de software (SCM). Un buen consultor debe conocer los detalles de entrada y salida, pero también saber cómo encaja en el panorama general. Al igual que espera que un consultor de Java EE sea experto en Java, pero sepa lo que significa entregar la aplicación empresarial a un cliente.

En la empresa que trabajé, teníamos un tipo responsable del SCM que había sido colaborador de Maven. Y su punto de vista era mucho más amplio que "solo" maven. Estaba a cargo de tener un proceso productivo de compilación, configuración y lanzamiento. Dos ejemplos:

• Nos codificación dura el número de versión en código Java para poder mostrarlo en el "sobre" de diálogo de nuestras aplicaciones de escritorio. La mayoría de las veces nos olvidamos de cambiarlo después del lanzamiento, lo que resulta en una falta de coincidencia entre el número de versión real y el diálogo de acercamiento, un gran problema para los integradores en el sitio. Esta fue una mala práctica. Luego configuró algo para que el número de versión en Maven fuera correcto en el archivo manifest y nos educó para que leamos el archivo manifest de Java para garantizar que ambas coinciden.

• Cuando se liberaría un módulo, escribió un guión, no sólo para generar la aplicación, sino también cerrar la versión correspondiente en el sistema de tickets (JIRA) y empuje las notas de la versión en el wiki.

Todo esto para decir que el conocimiento de cómo "mavenize" un proyecto es importante, pero más importante, el hombre debe entender cómo se trabaja actualmente, lo que está en su lugar y le ayudará a configurar algo razonable para mejorar su productividad.

Answer 5

Si tiene el lujo, le sugiero que el consultor venga al sitio por un día, le proporcione un proyecto de java existente en el que esté trabajando y haga que lo "mavenize" por usted. Al día siguiente, siéntense con él y pídales que expliquen cómo compilar y construyan un frasco (o guerra).

O tal vez hacer que vengan a la entrevista con un proyecto de maven para demostrar. El debería poder compilar, y construir una jar/war al menos, imo. Si pueden ejecutar pruebas unitarias, implementar en tomcat, integrarse con cualquiera de los diversos frameworks como gwt, hibernate, spring, etc., y aún mejor.

Answer 6

Muchas buenas preguntas aquí, especialmente las propuestas por Pascal Thivent. Sin embargo, haría otra pregunta:

P: ¿Cuál es la diferencia entre la agregación y la herencia en Maven?
A: Puede tener una breve explicación here.