Посібник для майбутнього Java розробника. Enterprise - частина 1

«Не надто пишайтеся цими технічними досягненнями, які ви збудували. Здатність знищити планету – ніщо в порівнянні з могутністю Сабо», – Дарт Вейдер про Зірку Смерті.

Intro

Напевно, наступні дві частини з циклу статей для багатьох найочікуваніші, і недарма. Що ж там, за горизонтом, за чистою Java? Чим дихають Java девелопери у кожному проекті? Вважайте це справжнім повноцінним посібником для самонавчання будь-якого back-end engineer'а середньої руки, для якого основна мова програмування - саме Java. Я маю намір охопити максимально середнє значення по лікарні та описати не лише найбільш популярні фреймворки, а й рішення, які вважаються актуальними на даний момент. Природно, інструментів дуже багато, і зрозуміти, які є найважливіші та найкращі – це шлях у нікуди. Кожен із вас розглядав розділ «Робота»на DOU і знаходив стек технологій, які постійно повторюються від вакансії до вакансії. Розумію, описати все неможливо, але придумати загальні рамки — цілком, тому спробуємо дотримуватися цього напряму. Якось у минулому, на одному з проектів стався досить цікавий конфуз, який, я думаю, повторювався і повторюється постійно у багатьох у тій чи іншій галузі. Було поставлене завдання — до готового функціонала прикріпити рендер однієї HTML-сторінки просто для того, щоби показувати статус окремих сутностей. У результаті мій колега вирішив прикріпити spring thymeleaf, який тягнув за собою частину core залежностей самого Spring, коли при цьому спринг ніхто не використовував. І це все для однієї звичайної сторінки, яка просто показує статус 2-3 сутностей. «Ніколи не бачив особливого сенсу використовувати два світлові мечі ... на мій погляд, це випендреж»- Обі-Ван Кенобі. З одного боку, розробник вирішив завдання максимально швидко, прикрутив фреймворк, з яким мав досвід користування та інтегрував його в проект за лічені години. Але з іншого боку, наша програма зросла в розмірах, тому постає просте запитання: чи правильно він вчинив? Для таких атомарних завдань, коли ти точно знаєш, що більше цей 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 Досить ілюстроване видання, приділяється увага і networking і девайсам, resource management. Йдемо далі? Є чудова книга, яка, до речі у мене десь тут ... ага (струшує пил) ... ось вона! Unix та Linux: керівництво системного адміністратора. Еві Немет.Досить велике керівництво, непогано перекладене. Чесно зізнаюся, я особисто не подужав, але основи адміністрування (перша частина) мені дуже сподобалися. Природно, не можна пройти повз Shell scripting. Краще спробувати це все на практиці, ну, а з книжок можна переглянути Learning the bash Shell. Така величезна кількість літератури з 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 . Для підвищення рівня підійде створення свого плагіна. Не замислюйтесь про те, який саме плагін потрібно створити, адже багато вже є! Спробуйте створити якийсь аналог, вивчіть фази як двічі по два.

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. Загалом досить смачна штука. Не бійтеся використовувати Ant/Maven/Gradle у контексті вашої IDE. Ці інструменти тісно інтегровані в Eclipse/IDEA і використовувати ці тулзи в контексті IDE досить комфортно.

Continious Integration

Theory

Це програми-ангели, які бережуть вас від звільнення. Якщо коротко, це софт, який стежить за змінами коду, білдить і ганяє написані вам тести. Якщо все добре після кожного комміту/мержа, то білд світиться приємним зеленим/синім світлом. Як тільки ви щось зламаєте, CI система одразу повідомить про це. Втім, трохи теорії – це до класики! Continuous Integration: Improving Software Quality and Reducing Risk до 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 (Part 1 of 9) — Introduction). Я вважаю, що TeamCity є інтуїтивно простий, і документація на високому рівні. Але якщо ви вважаєте, що є якась цікава книга, будь ласка, залиште це в коментарях. Звичайно, я перерахував лише малу частину цих CI систем, але у нас обмежено за обсягом. Напевно, найкращим керівництвом для вивчення буде лише практика. Встановив собі на комп'ютер, позапускав, повалив/відновив білди і ліг спати. І потім можна сміливо нести мені заліковку (якщо хочете:).

Version Control System

Багато говорити про VCS не варто. Це просто те, що має бути, і без чого управління проектом було схоже на мезозойську еру. Подібно до CI систем, давайте розглянемо два найпопулярніші рішення: Git і SVN.

Git

Наш Git зарекомендував себе як стабільну розподілену систему управління версіями. Почніть вивчення звідси і пройдіть усі розділи з налаштованим Git'ом у себе. Потім є чудова серія інтерактивних туторіалів від Code School. Також є від них короткий посібник 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, є чудова маленька книга Practice 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

З цим монстром не так просто розтанути: близько 40 бібліотек на всі випадки життя, від усіх відомого commons.lang до валідації xml, від DBUtils до commons.io . Звісно, ​​знайомитися з усім не потрібно, але Cookbook книги та туторіали буде корисно мати при собі. Наприклад, щоб зрозуміти, що собою представляє взагалі Apache Commons, можна погортати Jakarta Commons Cookbook by Timothy O'Brein

Висновок

Enterprise настільки неосяжний, що починати обговорювати відразу JavaEE та інші фреймворки було б безглуздо без усього, що цей Enterprise оточує. Тому у другій частині ми будемо фокусуватися на кожному шарі з multitier архітектури, розглянемо services тощо. Дуже дякую за увагу. Кінець першої частини. Попередні частини циклу:

1. Посібник для майбутнього Java розробника. Основи Java
2. Посібник для майбутнього Java розробника. Елегантний код

Оригінал із DOU