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

Question

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

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

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

Answer 1

На мой взгляд, "консультант Maven" должен:

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

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

Answer 2

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

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

Answer 3

Я бы спросил:

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

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

EDIT

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

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

• Мы жестко запрограммировали номер выпуска в java-коде, чтобы отобразить его в диалоге «about» наших настольных приложений. Большую часть времени мы забыли изменить его после выпуска, что привело к несоответствию между фактическим номером выпуска и диалоговым окном о программе - большая проблема для интеграторов на месте. Это была плохая практика. Затем он что-то настроил так, чтобы номер выпуска в Maven был правильным в файле manifest, и научил нас читать файл manifest с Java, чтобы убедиться, что оба совпадают.

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

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

Answer 4

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

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

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

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

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

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

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

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

a.s.o.

Answer 5

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

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

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

Answer 6

Если у вас есть такая роскошь, я предлагаю пригласить консультанта на один день, дать ему / ей существующий проект Java, над которым вы работаете, и попросите его / ее «придумать» его для вас.На следующий день посидите с ним / ней и попросите их объяснить, как собрать информацию и построить банку (или войну).

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