Java Enterprise: что и как учить
Я выступал с аналогичной темой на IT fest, и, судя по реакции зала, людям было интересно. Формат доклада сжатый, многое пришлось проговаривать уже потом, отдельно от выступления. Да и качество записи вышло не очень, не всё слышно. Поэтому решил написать статью.
Сначала о себе любимом. У меня достаточно большой опыт работы java-разработчиком (с 2001 года, даже считать страшно), а программистом и того больше — с
Я это всё рассказал не ради хвастовства, а для того, чтобы пояснить, на чём я основываюсь, говоря о списке технологий и порядке обучения.
Итак, начнем, и внезапно с конца — я соберу выводы, которые сделал из обучения молодых специалистов.
Первый вывод самый печальный — программистами могут стать не все. И нечего смеяться! Изначально я рассчитывал, что научиться программировать может любой. А чего там, программирование — откровенно не rocket science. Бери больше, кидай дальше. Но всё оказалось не так. Всё уперлось в мотивацию. Сейчас объясню.
Не бывает людей вообще без способностей к программированию. Но всё равно — все люди разные. Так вот, обучаясь (в том числе и программированию), вы тратите мотивацию. Достигая чего-то в процессе обучения — вы мотивацию восполняете. И чем меньше у вас способностей, тем тяжелее вам продвигаться до очередного достижения. Если у вас было не так уж много мотивации, вы рискуете просто до следующего достижения не доучиться. А другой человек, возможно с меньшей мотивацией, чем у вас, но с большими способностями просто будет щелкать задачи как орехи и доучится. Се ля ви.
Второй вывод. Учиться java-разработчику без ментора, работающего в этой сфере — невозможно. Наша индустрия полна огромным количеством невнятных и даже контр-интуитивных знаний о том, как надо поступать и как не надо. Сами вы в этом не разберетесь. Гарантированно.
После конференции меня спрашивали — так что же делать, если наставника нет? Отвечаю: найдите себе ментора. Понимаете, программистам тоже надо расти, из миддлов становиться сеньорами, из сеньоров — тимлидами и так далее. И для всего этого надо получить опыт руководства, общения с подчиненными. И где его взять? Тут проблема та же самая, что и у джунов — нужен опыт, чтобы получить определенную работу. А получить его можно только на этой работе. Так что помогите друг другу.
Где найти такого ментора? Потусуйтесь на форумах программистов (на том же DOU) — постучитесь к людям в личку с вопросом: «Простите, а можно я буду вам время от времени вопросы задавать?» Большинство согласится. Полазьте на линкедин, в конце концов.
Третье. Самое важное, что делает java-разработчика java-разработчиком — привычка и способность быстро находить знания и впитывание их с необходимой скоростью. Именно на это должен быть нацелен процесс обучения джавистов. Учить их по классической университетской схеме (лекции, семинары) — бессмысленно. Только по жестокой схеме: раскачали и кинули в омут. Кто сможет — выплывет. Ну а если человек не может совладать с тем, что кроме него никто задачу не решит («есть ты и есть задача, все остальное зависит от тебя»), то ему программистом не стать. Другой разговор, что задачи должны быть подобраны с правильной сложностью — чтобы их можно было решить, но для этого требовалось напрячь все возможности.
Пока это только основные наброски (задачи уже есть и неплохо себя зарекомендовали, но критерии оценки результата пока чистая вкусовщина менторов), а хочется иметь точный план учебы со всеми реперными точками. Я над этим работаю, как будет готово, сразу сообщу. Предварительные наброски — в конце статьи, можете сразу переходить туда.
Что же должен знать java разработчик
Здесь я просто приведу список, а потом раскрою все пункты отдельно:
— Core Java;
— ООП;
— JDBC;
— Servers + Servlets +JSP;
— Spring;
— ORM;
— Web-frameworks;
— Web-services (SOAP, REST);
— SQL, HTML, JavaScript;
— Специфичные требования.
Core Java и ООП
Меня постоянно спрашивают, что я имею в виду под знанием ООП. Рассказываю. Прежде всего, это означает свободно ориентироваться в трёх принципах ООП. Понимать, как работает наследование и полиморфизм. То есть если один класс наследуется от другого, кого и к чему надо приводить, а что автоматически является экземпляром чего. Если у базового класса и у дочернего есть метод с одинаковой сигнатурой, то какие именно ограничения накладываются на типы принимаемых и возвращаемых значений, а также бросаемых исключений. Что будет в compilation time, а что в run time. Ну и так далее. Человек, который этого не понимает, нормальный код не напишет — это уже проверено. Лично мы таких просто не берем, даже если у человека хорошие знания фреймворков. Себе дороже будет потом его код поддерживать.
Из Core java нужно знать методы объекта Object и Collection Framework. Enterprise java — это на 90% ковыряние в разных коллекциях. От них никуда не уйдешь.
Так же часто спрашивают про concurrency. Отвечу несколько спорно, но по моему опыту так. Есть проекты, которые жестоко завязаны на многопоточность. Для найма в эти проекты вас буду жестоко гонять по concurrency. В других проектах многопоточности особо нет, и вас там про нее ничего не спросят. Думаю, общее представление иметь необходимо всем, учить ли глубже — сами решайте. Другой разговор, что есть множество собеседователей, которые страшно любят эту тему и будут вас по ней спрашивать, даже если для проекта это все нафиг не надо. Почему именно многопоточность пользуется у них такой большой любовью — тут я только руками развожу.
JDBC (Java Database Connectivity)
Зачем учить то, чем никто уже в чистом виде не пользуется? По двум причинам.
Во-первых, новичков любят нанимать на проекты поддержки (support). А это в большинстве своем весьма древний софт, написанный кем-то левой задней. И вероятность того, что там используется plain JDBC — не нулевая.
Во-вторых, под капотом у всех ORM-ов все равно лежит тот же самый старый добрый JDBC. И рано или поздно (скорее рано, чем поздно), когда у вас что-то сломается, вы увидите как раз ошибки JDBC. И с этим надо будет что-то делать
Servers
Тут все просто. Любой java разработчик должен знать Tomcat. Он самый простой, самый легкий и пожалуй, имеющий наибольшую knowledge base. Спрашивать на собеседовании о нем вас никто не будет — предполагается, что вы его и так знаете. Не знать томкет — это стыд и позор. Имейте в виду.
Дальше стоит изучать уже JBoss/WildFly — всё-таки многие J2EE технологии на томкете не работают (те же EJB или кластерное решение, хотя, может, я отстал от жизни). А вот JBoss/WildFly — как раз оптимален. Он бесплатен и вполне функционален. Никто не ожидает от новичка, что он взял и скачал где-то WebLogic и фигачит код под него. А вот знание JBoss/WildFly — самое оно. Более того, он частенько используется даже у серьезных заказчиков
Unix-like
Про знания юникса вас могут максимум спросить — владеете ли и на каком уровне. Сразу отвечаю — достаточно владеть на уровне пользователя. Запустить, остановить, воспользоваться SSH и SCP. Ну в общем-то и все.
Servlets + JSP
Этот пункт аналогичен пункту про JDBC. И встречаются они всё-таки иногда, и знание того, что под капотом более современных web фреймворков — очень полезно. Как минимум, сокращает время нахождения ошибки в разы. Лишним не будет. Да и спросить на собеседовании об этом вполне могут.
Spring
Знание спринга — ультимативно. Как минимум, потому что спринг — отраслевой стандарт. И не важно, нравится вам спринг или нет. Главное, чтобы вы его знали. С вероятностью 80% вы будете с ним работать уже на одном первых трёх проектов. Да и вообще, энтерпрайз разработчик не должен перебирать — это хочу, это не хочу. Взялись и работаем. Вот это как раз тот случай.
Есть ещё CDI, стандарт от Оракла. Я провел опрос среди своих друзей, спрашивая, кто им пользуется. 80% ответили: «А что это такое?. Остальные 20% сказали: «Нет, не пользуемся». Так что можете смело на него забить.
ORM
Промышленным стандартом является Hibernate. Опять же, нравится он вам или нет, знать вы его обязаны. Использовать должны через JPA.
Объем знаний: уметь замепить отношения один-к-одному, один-ко-многим и многие-ко-многим. Написать HQL запрос и настроить лейзи загрузку.
Web-framework
В этом пункте всё-таки вкусовщина, но знание какого-либо веб-фреймоврка необходимо. JSF, так JSF. SpringMVC, так SpringMVC. Всё будет хорошо. Главное, чтобы вы могли хоть каким-то образом отрисовать UI. Все веб-фреймворки сходны в принципах работы, так что учите то, что покажется наиболее востребованным.
Web-services (SOAP, REST)
Ну, с REST вообще всё просто. От джавера там нужно только аннотацию повесить. И в принципе представлять, как оно работает.
С SOAP сложнее — надо знать несколько ключевых слов, описать, для чего служит WSDL, ну и представлять общие основы протокола.
SQL, HTML, JavaScript
Знание SQL — ультимативно. Вы должны его знать на уровне джавы. Сейчас даже на проекты, использующие NoSQL базы, не берут без хорошего знания SQL. Что уж говорить об остальных. Почему он так нужен — объяснять не буду, но если вкратце — на SQL вы будете писать часто и много. Естественно, не хранимые процедуры (хотя это тоже не исключено, но это всё-таки экзотика), но запросы на вставку и проверку тестовых данных — очень часто.
Я не беру людей на должность в двух случаях. Если они заваливаются на первом пункте (Core Java и ООП) и на этом. Делайте выводы.
Насчет знания HTML я даже говорить не буду. Чего там знать? Прочитал статью — ты уже его знаешь.Естественно, все хитрости и заморочки современных CSS — это хлеб Front End. Вот пусть они там и пасутся. Мы же должны хорошо знать HTML и немного JavaScript. Причем, знание JavaScript — отличный бонус для новичка. Знаете почему? Потому что новичков любят брать на саппортовый проект, в котором давно уже не работают дизайнеры. Java-скриптик подправить иногда надо, а джаверы его не любят. И если вы, в отличии от остальной команды, готовы им заниматься — все будут вас любить. И вы с бОльшими шансами попадете на работу, чем чистоплюи, которые не хотят ковыряться в этом вашем фронт-энде. Так что любите JavaScript, и будет вам счастье.
По объёмам знаний. Надо знать сам JavaScript. Хорошо также уметь читать JQuery. А ещё лучше — уметь его писать. Если вы обладаете соответствующим опытом — не стесняйтесь указать их в резюме. Это смежные с нами знания. Это вам не PHP какой-нибудь, про который джаверы говорят: «У тебя до сих пор есть в резюме PHP, тебе не стыдно?»
Знания скриптовых языков (sh, bash, perl &etc) — штука полезная. Как минимум, вы увеличиваете свои возможности по затыканию дыр — а это и есть основная суть работы на саппортовом проекте. Другой разговор, спрашивать вас об этом на собеседовании не будут, а выучить основы такого языка — дело пары дней. Так что я бы не советовал в это упираться.
Специфичные требования
Вы должны быть готовы, что при приеме на работу вас первым делом спросят: «А знаете ли вы фреймворк бла-бла-бла 4.2?» Нормальный ответ — нет, не знаю. В любом проекте есть какие-то странные вещи, которые только там и используются. Все знать вы не можете и не должны даже пытаться.
Как выбрать специализацию
Очень советую всем начинающим программистам выбрать себе специализацию. Сейчас объясню, что я имею в виду. Мы все — java-разработчики. Ок, все знают джаву, все знают более менее полный стек наших фреймворков. Но, в любом проекте будет цениться человек, который реально хорошо знает один из нужных фреймворков. Например — гуру по Hibernate. Или гуру по какому-нибудь PrimeFaces. Или — мощный знаток Oracle DB.
Вы поняли, к чему я. Да, знать нужно все, но что-то одно — выучить досконально. И поразить своими глубокими знаниями об устройстве вашего любимого фреймворка собеседователя. Да, естественно не в каждой команде нужен специалист именно по вашему любимому фреймворку. Там вы просто будете обычным джавером. Но в какой-то команде ваше появление будет встречено аплодисментами — «О! именно ты и был нам нужен, тебя нам послало небо!» Короче, вы поняли. Будьте как все, но немножко лучше :)
В каком порядке всё это изучать
Значит так, сначала ставим цели. Мы должны добиться того, чтобы новичок не боялся чудовищного массива знаний и привык к тому, что всё он не будет знать никогда. И научился работать в ситуации неполного знания.
Пока методика выглядит следующей:
1. Погрузиться в сложные алгоритмические задачи. Главное, чтобы эти задачи еще не были реализованными в готовых библиотеках, и человек понимал, что задача относительно реальная. Например — вывести что-то отформатированное. Смысл: вызывать у человека понимание, что любая задача решаема. Просто нужно несколько дней подумать, покрутить задачу, и вот тогда все выйдет.
2. Нарисовать к этим задачам Unit tests. Юнит тесты легко покажут все ошибки вашего проектирования и заставят переписать код в гораздо более приличном формате. Как бонус — студент привыкает не бояться править код снова и снова. Это умение абсолютно необходимо для профессионального программиста
3. Научиться декомпозиции. Выбрать несколько предметных областей и порисовать по ним UML диаграммы. Это необходимо, чтобы просто понять — это и будет самым сложным в нашей работе. Единственное замечание — диаграммы должны проверяться опытным и толковым ментором. На этом этапе ментор просто необходим. Настроить свой мозг на вырезание скоупа проекта, на декомпозицию объектов и их взаимосвязей — это то, что само не придет, сколько не программируй.
4. Сделать код на основе результатов одной из декомпозиций. Этот код будет впоследствии нашим слоем бизнес-логики.
5. Начинать работу с базой. Освоить JDBC и все его части. Это будет существенно проще после предыдущего пункта. Код также необходимо показать ментору. Как показывает моя практика, многопоточность (которая в любом случае предполагается для этого кода) — штука не сразу лезущая в голову. Надо, чтобы вас направили.
6. Выучить основы веба и томкет. Надо сделать к вашей бизнес-логике и DAO layer последнюю оставшуюся часть — UI. Пока на сервлетах и JSP. Нужно сделать так, чтобы JSP обращались к бизнес-логике за ее данными. Та запрашивала данные из базы и возвращала их на View (JSP). По нажатию на кнопки в JSP управление передавалось в сервлеты, которые отправляли команды бизнес-логике на изменение состояния. А та, в свою очередь, меняла данные в базе с помощью DAO layer. И затем сервлеты отправляли управление обратно на JSP (например — редиректом), и затем все повторялось. Тут надо внимательно следить, чтобы никакие запросы от JSP не лезли в DAO layer.
7. Изучить возможности томкета. Создаем Data Source и работаем уже не с физическим коннектом, а с логическим, получая его через JNDI.
8. Освоить Spring. Все, что нужно сделать — проинжектить DataSource в нужные классы DAO Layer. Сначала — через XML конфигурацию, а потом — через аннотации. Этих знаний будет достаточно
9. Теперь можно вводить Hibernate через JPA аннотации. Смысла изучать меппинг-файлы я не вижу. Они уже почти нигде не используются. Заменяем весь код в DAO на HQL или Criteria. Что лучше пойдет.
10. Ну и наконец, самое веселое — выбираем фреймворк для морды. Я бы порекомендовал какой-то JSF или SpringMVC.
Дальше, когда ключевые вещи освоили, изучать можно уже что угодно. Я бы рекомендовал погрузиться в SQL, WebServices и JavaScript
Обращаю внимание: перескакивать этапы крайне не советую.
Если у вас получится следовать этому плану, и ваш ментор окажется достаточно квалифицирован, всё будет отлично. И скоро на одного Java разработчика станет больше. Удачи вам!
