Вопросы для определения знаний Maven

Я попросил Maven тренироваться на работе, и боссы хотят нанять кого-то, кто знает, что Maven будет работать с нами в качестве консультанта, чтобы мы узнали Maven с реальной точки зрения, а не с точки зрения обучения.

Мне было поручено задавать различные трудности, чтобы спросить потенциальных наемников, чтобы выяснить их способность Maven. Проблема в том, что я пока не совсем понимаю Maven (отсюда и запрос на обучение).

Какие вопросы вы попросили бы кого-то определить их способность Maven и какой уровень знаний должен был иметь Maven для ответа на них?

Ответ 1

По моему мнению, "консультант Maven" должен:

Хорошее понимание того, как Maven отличается от других инструментов построения, таких как Ant (Maven предоставляет "lingua franca" для управления проектами).
Хорошее понимание принципов Maven: соглашения по конфигурации, макет по умолчанию, соглашения об именах, философия инструмента (один первичный вывод для каждого проекта).
Хорошее понимание того, как работает Maven: от того, откуда идут конвенции (супер POM), жизненные циклы (основной, чистый, сайт), фазы, как плагины привязаны к фазам, влияние упаковки, и т.д.
Знайте, какие профили и как их можно использовать для работы с разными средами, как их запускать.
Знать, как использовать плагины, как их настроить, как подключить их к сборке maven.
Узнайте, как работают репозитории, разница между локальными и удаленными репозиториями, каковы зависимости SNAPSHOT.
Узнайте, как решаются зависимости, какие транзитивные зависимости, как их контролировать, какие области зависимостей, как использовать dependencyManagement.
Знать, как реализовать проверки работоспособности кода, необходимые плагины (Checkstyle, PMD и плагины Findbugs), как реализовать различные типы тестов (единицу, интеграцию, функционал), как измерить охват, когда сбой сборки, когда сообщать.
Знать, как настроить maven в корпоративной среде (используя общий репозиторий, настроить CI, компанию POM).
Знайте, как обращаться с расширенными сценариями упаковки (с плагином сборки)
Узнайте, как обрабатывать развертывание, различные протоколы, плагин развертывания, плагин выпуска, разрешение SNAPSHOT.
Знайте, как настроить сборку Maven для проекта Java EE, как настроить сборку нескольких модулей, какие модули необходимы, как протестировать в среде разработки, как обрабатывать производственную среду.

Кто-то, у кого есть эти навыки, должен поставить вас на правильный путь (и, скорее всего, это достойный опыт Maven).

Ответ 2

Здесь есть много хороших вопросов, особенно те, которые предлагаются Pascal Thivent. Однако я задал бы другой вопрос:

Q: В чем разница между агрегацией и наследованием в Maven?
A: У вас может быть короткое объяснение здесь.

Ответ 3

Я бы предложил вам подумать о том, что вы хотите сделать с Maven, или почему вы хотите представить его в своих проектах. Возможно, спросите своего босса за его причины/цели при введении Maven.

После того, как вы назвали свои основные цели , почему, чтобы ввести Maven. Спросите потенциальных консультантов , как они будут использовать Maven для достижения этих целей.

Примеры 1
Цель: улучшить общее качество кода в проекте.

Вопрос: Как мы можем использовать Maven для улучшения нашего общего качества кода в проектах.

Возможный ответ: у Maven есть несколько подключаемых модулей, чтобы заставить /meassure качество кода в проектах, мы могли бы интегрировать их в наши скрипты почти мгновенно. (например, checkstlye, pmd, cobertura, xradar...)

Примеры 2
Цель: создание сценариев автоматического развертывания для нескольких целевых сред.

Вопрос: Как мы можем использовать Maven для автоматического развертывания артефактов в нескольких целевых средах.

Возможный ответ: мы могли бы использовать плагины Maven для развертывания (например, Cargo) и использовать профили maven для обработки нескольких конфигураций.

a.s.o.

Ответ 4

Я бы спросил:

Опишите, что такое практика SCM?
Опишите вашу идеальную инфраструктуру Maven (сервер, репозитории, CI, плагины, соглашения и т.д.)?

Оба являются очень открытыми вопросами, но они должны дать вам ощущение его навыков и того, что вы можете узнать у него и что он может принести вашей компании.

ИЗМЕНИТЬ

Maven - всего лишь одна часть общей стратегии управления конфигурацией программного обеспечения (SCM). Хороший консультант должен знать детали входа и выхода, но также знать, как он вписывается в общую картину. Так же, как вы ожидаете, что консультант Java EE будет экспертом в Java, но должен знать, что значит предоставлять корпоративное приложение клиенту.

В компании, в которой я работал, у нас был парень, ответственный за SCM, который был автором Maven. И его взгляд был более широким, чем "просто" maven. Он отвечал за создание продуктивной сборки, конфигурации и выпуска. Два примера:

Мы были жестко кодированы номер версии в Java-коде, чтобы отображать ее в диалоговом окне "about" наших настольных приложений. Большую часть времени мы забыли изменить его после выпуска, что привело к несоответствию между фактическим номером выпуска и диалогом - большая проблема для интеграторов на месте. Это была плохая практика. Затем он установил что-то, чтобы номер выпуска в Maven был правильным в файле manifest и научил нас читать файл manifest с Java, чтобы гарантировать совпадение.
Когда вы выпустили модуль, он написал script, чтобы не только создать приложение, но и закрыть соответствующую версию в системе билета (JIRA) и нажать заметки о выпуске в вики.

Все, что сказать, что знание того, как "заманивать" проект важно, но что более важно, парень должен понять, как вы сейчас работаете, что находится на месте и помочь вам создать что-то разумное, чтобы повысить производительность.

Ответ 5

Вот вопросы, которые я задал бы:

Как бы вы применяли JDK6 для группы проектов?
Как бы вы применяли конкретная версия плагинов?
Каковы некоторые причины, по которым вы будет использовать сборку для сборки банки а не плагин jar?
Опишите процесс освобождения Проект Java EE, состоящий из EJB, WAR файл и две служебные банки.
Сколько репозиториев должно сервер внутреннего хранилища серверов и почему?
Как бы вы структурировали проект POM, состоящий из N дочерних проектов, чтобы их можно было легко использовать в Eclipse?

Все эти вопросы имеют как минимум два ответа. Я бы искал кого-то, кто может предоставить хотя бы два ответа и указать на плюсы и минусы каждого подхода. В идеале, этот человек должен подстраивать настройки таким образом, чтобы быть менее разрушительным для того, как работает ваша среда.

Ответ 6

Если у вас есть роскошь, я предлагаю, чтобы консультант приходил на место в течение дня, дайте ему/ей существующий проект java, над которым вы работаете, и попросите его "mavenize" для вас. На следующий день сядьте с ним/им и попросите их объяснить, как скомпилировать, и построить банку (или войну).

Или, может быть, они придут на собеседование с проектом maven, чтобы продемонстрировать. Он должен скомпилировать и, по крайней мере, построить банку/войну, imo. Если они могут запускать модульные тесты, разверните их в tomcat, интегрируйте их с любой из различных фреймворков, таких как gwt, hibernate, spring и т.д., А затем еще лучше.