«Не слишком гордитесь этими техническими достижениями, которые вы построили. Способность уничтожить планету — ничто по сравнению с могуществом Силы», — Дарт Вейдер о Звезде Смерти.
Intro
Наверное, следующие две части из цикла статейдля многих самые ожидаемые, и неспроста. Что же находится там, за горизонтом, за чистой Java? Чем дышат Java девелоперы в каждом проекте? Считайте это настоящим полноценным руководством для самообучения любого back-end engineer’а средней руки, для которого основной язык программирования — именно Java.
Я намерен охватить максимально среднее значение по больнице и описать не только наиболее популярные фреймворки, но и решения, который считаются актуальными на данный момент. Естественно, инструментов очень много, и понять, какие есть самые важные и лучшее — это путь в никуда. Каждый из вас рассматривал раздел «Работа»на DOU и находил стек технологий, которые постоянно повторяются от вакансии к вакансии. Понимаю, описать все невозможно, но придумать общие рамки — вполне, поэтому попробуем следовать этому направлению.
Как-то в прошлом, на одном из проектов случился довольно интересный конфуз, который, я думаю, повторялся и повторяется постоянно время от времени у многих в той или иной области. Была поставлена задача — к готовому функционалу прикрепить рендер одной HTML-страницы просто для того, чтобы показывать статус отдельных сущностей. В итоге мой коллега решил прикрепить spring thymeleaf, который за собой тянул часть core зависимостей самого Spring, когда при этом спринг никто не использовал. И это всё — для одной обычной страницы, которая просто показывает статус
«Никогда не видел особого смысла использовать два световых меча...на мой взгляд, это выпендреж» — Оби-Ван Кеноби.
С одной стороны, разработчик решил задачу максимально быстро, прикрутил фреймворк, с которым имел опыт пользования и интегрировал его в проект за считанные часы. Но с другой стороны, наша программа выросла в размерах, поэтому возникает простой вопрос: правильно ли он поступил?
Для таких атомарных задач, когда ты точно знаешь, что больше этот thymeleaf/ Spring MVC и т.п. нигде использоваться не будет, лучше вообще не использовать. Меня всегда удивляют фразы типа «О! Да мы тут заюзали Hibernate! Посмотри, всё круто, ORM!», а на закономерный вопрос, можно ли здесь было обойтись обычным JDBC, они пожимают плечами.
Есть обыкновенная архитектура, которая должна быть простая, к которой следует относиться с трепетом, не загромождать ее модными и супер современными фреймворками. Как сказал выше Оби-Ван, это не больше чем выпендреж, хотя уметь пользоваться ими необходимо.
Молодому джависту, на мой взгляд, не повезло больше всех — столько спецификаций, столько библиотек, которые нужно изучать. Одна только Java EE включает в себя документаций выше крыши. Возникает вопрос, за что браться новичку, что учить дальше, что делать после Хорстмана? Простой ответ: к сожалению, знакомиться со многим. И мы начнем не с бизнес-фреймворков, а с более приземленных необходимых вещей.
Operating Systems
Linux
Помимо винды или/и уютного Yosemite необходимо с улыбкой протянуть свои руки к Linux. Для одних проектов достаточно быть юзером, уметь обращаться с командной строкой, для других — куда больше. Какой способ лучше всего? В интернете книг/туториалов просто тьма.
Начните с установки Ubuntu или любого другого симпатичного вам дистрибутива и попробуйте использовать его как основную операционку ближайший месяц-два. Будет гораздо лучше, если вы начнете учить Java внутри Linux, компилируя и манипулируя файлами с помощью терминала.
The Linux Command Line by William Shotts. Читайте эту книжку не как роман «50 оттенков серого», а как полноценный интерактивный курс — открывайте терминал и повторяйте за автором.
Хочется основ и как устроен Linux? Не будем брать Computer Science и курс операционных систем — это в следующей части. Зайдите на edx.orgи попробуйте пройти несложный курс Introduction to Linux.
Есть еще книга из вышеупомянутой серии How Linux Works: What Every Superuser Should Know by Brian Ward. Достаточно иллюстрированное издание, уделяется внимание и networking и девайсам, resource management.
Идем дальше? Есть отличная книга, которая, кстати у меня где то здесь...ага (встряхивает пыль)..вот она!
Unix и Linux: руководство системного администратора. Эви Немет.
Достаточно большое руководство, неплохо переведенное. Честно признаюсь, я лично не осилил, но основы администрирования (первая часть) мне очень понравились.
Естественно, нельзя пройти мимо Shell scripting. Лучше попробовать это всё на практике, ну, а из книжек можно просмотреть Learning the bash Shell: Unix Shell programming by Cameron Newham.
Настолько огромное количество литературы по Linux/Unix невозможно охватить в полном объеме, да еще и в этой статье, где Linux находится на втором плане. Мой коллега по работе, который собаку сьел на этом деле, посоветовал достаточно практичную вещь:
Скачай ArchLinux и попробуй его поднять. В процессе обучишься по самое не хочу!
Windows
В резюме программистов встречается графа: «опыт Windows больше 10 лет». Я вас, конечно, поздравляю, что вы в контру шпилили с 10 лет на винде, но попрошу заблаговременно не вырыть себе яму на собеседовании, потому как на проекте, где идет тесная работа с IIS, batch/powershell, не дай Бог, реестром, собеседование окажется не реально тяжелым, и кроме ухмылки напротив сидящего тех. лида вы получите еще и дозу унижения. Это вам нужно? Ответ напрашивается сам собой.
Отложите свою пиратскую винду из торрента и попробуйте установить на какую-то виртуалку Windows Server. Изучите ее не только со стороны юзера и установки JAVA_HOME. В этом плане практически полноценное руководство сущестует в виде книги Mastering Windows Server 2012 R2 by Mark Minasi.
К примеру, если вы используете PowerShell, обратите внимание на прекрасную книгу Windows PowerShell in Action от Manning by Bruce Payette. Я понимаю, 1000 страниц пройти нереально, но ее как минимум можно держать при себе как справочник. Ничего другого не нужно, я считаю.
Как итог — обратите внимание на пробелы в своих знаниях по использованию Windows и поищите интересующую вас информацию в интернете.
Build Tools
Maven
Что главное нужно понять в Maven? Вот первые шаги и задачи:
1. Изучите, что Maven делает в каждой фазе, можно даже зазубрить. Это практически 80% успеха и даст вам наглядную картинку.
2. Создайте локально свои sandbox проекты с мультимодульной системой, с явным dependency management. Попытайтесь прикрутить сторонние библотеки, попробуйте создать что-то, используя их.
3. Поиграйтесь с profile
4. Разберитесь с plugin management и изучите список самых популярных плагинов на официальном сайте.
5. Исследуйте, как можно лучше использовать maven вам в вашем проекте. К примеру, parallel builds может существенно уменьшить время сборки.
Для быстрого погружения зайдите на русскоязычную версию сайта Apache Maven, пошерстите пару туториалов в гугле.
Всё никак не выйдет третье издание одной из главных книг по Maven. Пока что это второе издание руководства от Sonatype Maven: The Definitive Guide.
Кстати, та же Sonatype Company выложила в интернет и reference.
Для advanced уровня подойдет создание своего плагина. Не задумывайтесь о том, какой именно плагин нужно создать, ведь многое уже есть! Попробуйте создать какой-то аналог, изучите фазы как дважды два.
ANT
Данный инструмент выглядит куда полегче, поэтому и учить здесь особо нечего. До сих пор существует проекты, в которых инструментом сборки является только ANT. Это абсолютно нормально: ANT зарекомендовал себя как простой и понятный инструмент сборки в контексте управления маленькими атомарными тасками (ant tasks). Конечно же, здесь есть многие плагины, как и у Maven.
В качестве знакомства с ANT выполните следующее:
— Попробуйте манипулировать файлами и папками
— Реализуйте разный порядок выполнения тасков. На основе этого выучите зависимости и приоритет задач в ANT.
— Распакуйте и/или запакуйте zip архив. В тасках попробуйте поиграться с содержимым архива и так далее.
Не нужно предлагать кучу ресурсов для изучение ANT’a. Для более-менее глубокого погружения достаточно официальной страницы по apache ant. (ant.apache.org) и книги Ant in Action by Steve Loughran.
Gradle
Для меня Gradle ближе к ANT, чем к Maven, но его полноценно можно назвать сводным братом этих двух парней. У него присутствует и lifecycle, похожий на Maven, и гибкость тех же тасков, которые есть у ANT. Ну, а самое главное — Gradle не использует XML и, более того, с ним можно вытворять всё, что пожелаешь, если более-менее знаком с Groovy. В общем, достаточно вкусная штука.
Мне очень нравится официальная документация по Gradle. Стоит ли дальше заглядывать? Прекрасное руководство, обратите внимание на
Не бойтесь использовать Ant/Maven/Gradle в контексте вашей IDE. Эти инструменты тесно интегрированы в Eclipse/IDEA, и использовать эти тулзы в контексте IDE достаточно комфортно.
Continious Integration
Theory
Это программы-ангелы, которые берегут вас от увольнения. Если кратко, это софт, который следит за изменениями в коде, билдит и гоняет написанные вам тесты. Если всё хорошо после каждого коммита/мержа, то билд светится приятным зеленым/синим светом. Как только вы что-то сломаете, CI система сразу сообщит об этом.
Впрочем, немного теории — это к классике! Continuous Integration: Improving Software Quality and Reducing Risk by Paul Duvall. (она же — «Непрерывная Интеграция» на русском)
В этой книге даже рассматривается создание собственной CI системы.
Давайте остановимся на двух самых популярных решениях в этой области.
Jenkins
Jenkins, он же Hudson. Открытая, дружелюбная, простая в использовании апликуха.
Чтобы поближе познакомиться с Jenkins, попробуйте сделать следующее:
1. Скачайте его себе на комп. Установите и настройте JDK, Maven, ANT и всё, что вам нужно для проекта.
2. Создайте первый Job и укажите месторасположение вашего проекта, к примеру, главного pom.xml. Запустите, убедитесь, что у вас есть какой-то тест, чтобы было наглядно видно.
3. Научитесь запускать ваш проект с разными настройками и опциями.
4. Прикрутите разные плагины, посмотрите, как они работают в связке с вашим проектом.
5. Сконструируйте триггеры разных job’ов. Создайте небольшой pipeline.
6. Изучите DSL и попробуйте интегрировать его в Jenkins.
7. Настройте slave с другого компьютера и/или сделайте его регулярной тачкой для прогона билдов.
8. Создайте nightly билды.
Из книг достаточно почитать Jenkins: The Definite Guide by John Ferguson Smart. Толковое руководство с кучей скриншотов.
TeamCity
Да, TeamCity не бесплатен, но вы посмотрите, до чего же прекрасно он интегрирован в экосистему продуктов JetBrains. Intellij Idea и TeamCity — великолепный союз.
По большому счету, если вы уже знакомы с Jenkins, TeamCity не станет для вас темным лесом, и наооборот. Вместо slave — agents, те же триггеры и так далее. Но в отличии от Jenkins, TeamCity может похвастаться такими потрясающими фичами как, например, remote run, он же pre-tested commit, куда более наглядная статистика и еще много всего.
Мне очень нравится user guide на youtube, который сделала сама JetBrains (TeamCity User Guide (Part 1 of 9) — Introduction). Я считаю, что TeamCity интуитивно прост, и документация на высоком уровне. Но если вы считаете, что есть какая-то стоящая внимания книга, пожалуйста, оставьте это в комментариях.
Конечно, я перечислил лишь малую часть этих CI систем, но у нас всё ограничено по объему. Наверное, лучшим руководством для изучения будет только практика. Установил себе на комп, позапускал, повалил/восстановил билды и лег спать. И потом можно смело нести мне зачетку (если хотите :).
Version Control System
Много говорить про VCS не стоит. Это просто то, что должно быть, и без чего управление проектом было бы похоже на мезозойскую эру. Подобно CI системам, давайте рассмотрим два самых популярных решения: Git и SVN.
Git
Наш Git зарекомендовал себя как стабильная распределенная система управления версиями. Начните изучение отсюдаи пройдите все главы с уже настроенным Git’ом у себя. Затем, есть замечательная серия интерактивных туториалов от Code School. Зарегистрируйте свой аккаунт и откройте для себя Git Path, пройдите все уровни. Также есть от них же краткое руководство Try Git: Code School.
Из книг могу порекомендовать Version Control with Git by Jon Loeliger
Если вы так привыкли к черепашке (TortoiseSVN, прим. автора), и боитесь консоли, вы, конечно, можете скачать его аналог TortoiseGit, но, на мой взгляд, куда более приятным и эстетичным решением является продукт от Atlassian — SourceTreeApp.
Можно потренироваться с remote репозиториями, благо хост-сервисов в интернете достаточно. Если хотите, потренируйтесь локально. Нет? Тогда создайте аккаунт на GitHub и поработайте в полноценном режиме: сделайте пару коммитов, fork’ните какой-то opensource проект, сделай пару merge между бранчами и так далее.
SVN
Другая не менее популярная VCS — это SVN. Эта система не может похвастаться распределенностью. У каждой из них свои подходы, свои плюсы и минусы. Прочтите обязательно интересный разговор новичка и пользователя SVN.
Есть бесплатная книга от read-bean.comс русским переводом. Также будет крайне полезен мини-курс от TutorialsPoint. Не проходите мимо официального Apache сайта subversion.apache.org.
Самым интересным клиентом для меня является вышеупомянутый TortoiseSVN.
Из книг можно выделить одну: Version Control with Subversion by Michael Pilato.
Мне она понравилась тем, что здесь уделяется внимание администрированию самого SVN сервера. Надеюсь, я не упустил основные моменты.
Testing tools
Неплохо было бы разобраться на своих маленьких sandbox проектах, что такое юнит-тесты, интеграционное и регрессионное тестирование.
JUnit
Теория юнит-тестов хорошо описана в книгах из предыдущей статьи. В частности, «Clean Code» даже описывает junit как одну из популярных библиотек в этой области.
Но если касаться конкретно JUnit, есть замечательная маленькая книга Practical Unit Testing with JUnit and Mockito by Tomek Kaszanowski
Конечно, здесь не только JUnit и Mockito. Здесь автор знакомит и с Matcher’ами, и предлагает примеры parameterized тестов, и поверхностно проходит по TDD.
Есть также книга, которая вышла совсем недавно. Это Pragmatic Unit Testing in Java 8 by Jeff Langr
Авто знакомит с Hamcrest, описывает Best Practices, ну и, конечно, Java 8. Можно смело читать после книги Tomek’a.
Кстати, по поводу TDD. Я не хочу поднимать холивар по поводу того, стоит ли их использовать, плохо это или хорошо, нужны ли они заказчикам. Просто запомните: работать по TDD — не диковинка, и во многих проектах такая методология используется, и для многих людей это единственное и неоспоримое правило.
По теории можно прочитать классику. Kent Beck — Test Driven Development: By Example. Больше всего мне понравилась часть про паттерны TDD.
Как ни удивительно, есть хороший курс от первого лица — Let’s Play TDD (200 видео!) на Youtube. Не менее занимательна дискуссия самого Фаулера — стоит или не стоит применять TDD, портит ли он дизайн и тому подобное. Запомните просто раз и навсегда:
TDD не создает плохой дизайн, его создаете лично вы.
Если вы больше используете BDD (одно другому не мешает) и, к примеру, используете Cucumber на проекте, то это немного другая плоскость. Хорошая книга на этот счет — Manning BDD in Action: Behavior-driven development for the whole software lifecycle by John Ferguson Smart.
Кстати, John Ferguson Smart активно продвигает эту тему в массы. Если вы — скрам мастер или ПМ, которому наконец не режет глаза, а любо-дорого смотреть на when-if-then тесты, тогда обязательно подпишитесь на твиттер Джона.
По поводу Cucumber — просмотрите Java имплементацию на официальном сайтеи ознакомьтесь с книгой The Cucumber Book: Behaviour-Driven Development by Matt Wayne.
3rd party libraries
Немаловажно уметь использовать популярные библотеки, где это необходимо — они упрощают повседневную жизнь каждого Java разработчика. Из популярных решений можно выделить следующие:
Joda Time.Предлагает полностью заменить неудобные родные Date и Time более удобными JodaTime. Вот один хороший референс.
Обратите внимание, что если вы уже используете Java 8, то JodaTime мало чем поможет. Дело в том, что новый DateTime API полностью вытеснил это библиотеку, и местами даже хитро скопипастил. Согласно статье самого автора, каждый Joda класс может быть удобно заменен на аналогию из java.time.
Google Guava.Во многом Java 8 вытесняет даже Guava. Тот же Objects, Stream API, Java Predicate и много много всего предлагает заменить и вообще ее не использовать. Повторюсь, если у вас не Java 8 — лучше этого гидаи своих прямых рук ничего нет.
Apache Commons.С этим монстром не так-то просто растатьcя: около 40 библиотек на все случаи жизни, от всеми известного commons.lang до валидации xml, от DBUtils до commons.io. Естественно, знакомиться со всем не нужно, но Cookbook книги и туториалы будет полезно иметь при себе. К примеру, чтобы понять, что из себя представляет вообще Apache Commons, можно полистать Jakarta Commons Cookbook by Timothy O’Brein
Заключение
Enterprise настолько необъятен, что начинать обсуждать сразу JavaEE и другие фреймворки было бы глупо без всего, что этот Enterprise окружает. Поэтому во второй части мы будем фокусироваться на каждом слое из multitier архитектуры, расмотрим services и так далее.
Большое спасибо за внимание. Конец первой части.
Предыдущие части цикла:
— Пособие для будущего Java разработчика. Основы Java.
— Пособие для будущего Java разработчика. Элегантный код.