Что должен знать программист java – Обучение Java-программист: курс программирования на джава, java developer курс | GeekBrains — образовательный портал | GeekBrains — Вебджем.рф

Содержание

Как Программисту 1С стать Java developer’ом / Habr

Несколько лет назад, когда я искал пути из программистов 1С в Java developer’ы — я бродил впотьмах, пытаясь нащупать дверь, в существовании которой был не уверен. Я пытался найти истории успеха, но кроме пары комментариев ничего не нагуглил. Мир Java выглядел огромным, а количество фрэймворков бесконечным. Было совершенно непонятно: что учить, что не учить, что нужно в работе, а что никто не использует. Если ты хочешь в Джаву, теряешься в бесконечных названиях технологий и фрэймворков и хочешь узнать какие же из них надо изучать, а на какие не обращать внимания — эта статья для тебя!

Некоторые начальные допущения

в этой статье мы не будем обсуждать вопрос «зачем?», будем только — «как?». Если ты сюда пришел — ты сам знаешь зачем.
я никогда не получал образования как-то связанного с ИТ, поэтому мои рекомендации — это рекомендации от человека и для человека, который на момент начала изучения Java никогда ни на чем кроме 1Са не писал. Если у тебя диплом по разработке ПО — часть рекомендаций может быть лишней.
я постараюсь нарисовать картину, отражающую какую-то среднестатистическую вакансию. Естественно, если ты хочешь в какое-то узкое, специфичное направление вроде big data или наоборот embedded — тебе лучше узнать об этом направлении подробнее.

Плохие новости

Во-первых, если ты решил ~~предать 1С~~ перейти в Java разработку — не жди, что путь будет легкий и быстрый. Скорее всего, при должном усердии, ты потратишь никак не меньше полугода на подготовку, плюс никак не меньше года, чтобы вылезти из джунов.

Во-вторых, готовься, что если ты сейчас топовый 1Сник — твой доход скорее всего восстановится когда ты станешь уверенным middle’ом. Как правило, это не меньше 2-3 лет практики, но в конечном счете все зависит от тебя.

В-третьих, не жди, что твой 1Сный опыт тут кому-то интересен. У тебя может быть 100500 успешных проектов и вся стена в 1Сных сертификатах — это никого интересовать не будет. Ты будешь джуном, с тобой будут разговаривать как с джуном и у тебя будут задачи как у джуна. Но тут есть ложка меда: даже если ты не топовый 1Сник, в вопросах SQL, скорее всего, ты потягаешься с Senior Java developer’ами.

Еще пара очень заезженных советов, которые ты уже слышал три десятка раз, но поверь мне, они работают на 100%:

Тратить 1 час каждый день — это намного лучше чем тратить 7 часов раз в неделю. Если ты решил идти — иди. Без отговорок. Каждый день. Ладно, в воскресенье можешь отдохнуть.
Если ё инглиш из нот вэл — улучшай его! Это тот навык, который тебе пригодится: мало того что почти все, что ты сможешь прочитать, будет на английском, так тебе еще и код на нем писать! Скорее всего, первое что тебе потребуется — это навык чтения и понимания прочитанного. С listening и speaking можешь повременить.

Подготовка. Основы языка

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

Я выбрал Java. Все дальнейшие рекомендации будут даны в этом контексте, если ты выбрал другой язык — значительная часть написанного тут может потерять смысл, но общие идеи ты можешь почерпнуть. Вероятно, тебе стоит посмотреть в сторону PHP, ибо Битрикс и переход на него может оказаться проще в плане административного барьера (там 1С, тут 1С, какая разница?..) и в плане отсутствия в языке всяких стримов и метод-референсов (хотя они дико кайфовые).

Если ты тоже выберешь джава — не забивай себе голову Java EE, тебе нужна только Java SE. Что такое Java ME и Java FX вообще лучше не знать )

Итак, с чего же начать? Я не советую тебе бросаться покупать двухтомник Хорстманна и тысяче страничный «Spring 5 для профессионалов» и пытаться все это вызубрить. Даже если ты расскажешь все это наизусть — знания не подкрепленные практикой выветрятся очень быстро. Начни с онлайн площадок по обучению программистов. Я решал JavaRush. Дошел наверно до 15 уровня. Это заняло около 1-2 месяцев (с цифрами могу что-то наврать, дело было давно)

Затем принимайся за HackerRank. Не пугайся его названия — там можно выбрать уровень сложности и на простейшем тебе будут предлагать задачи уровня инвертировать строку. Добейся, чтобы задачи среднего уровня (medium, баллов на 30) решались без проблем. Хотя система оценок иногда дает сбой и бывают такие задачи на 30 баллов, что проще какой-нибудь hard на 60 баллов решить, но в основном ты должен справляться. Это займет тебя еще на 1-2 месяца.

Теперь пора читать Хорстманна. Имей ввиду, что это хорошая книга, но она покрывает Java целиком (только язык, не фреймворки) и даже те ее части, которые почти нигде не используются. Моя рекомендация: в первом томе забей на разделы связанные с UI и на весь второй том. И еще, если будет туго, в первом томе пропусти многопоточность и вторую половину дженериков — этого могут не знать даже мидлы, для джуна не страшно. Еще важно не попасть в ловушку версий: книга, которая называется Java 2 — это древность. Тебе нужна версия 1.8 или 9. Или ориентируйся на дату издания: 2015 год и позже подойдут.

Я надеюсь, во время чтения Хорстманна ты не бросишь HackerRank, может, даже решишь пару задачек баллов на 80-100. В целом, больше 60 баллов подниматься не нужно, потому что там начинается не столько прикладное программирование, сколько «искусство ради искусства». Но если ты чувствуешь в себе силы — иногда бери hard, лишним это не будет. И еще, имей ввиду, что большинство сложных задач — это классические алгоритмические задачи, которые ты можешь гуглить: смысл упражнений на хакерранке не в том чтобы придумать с нуля алгоритм, который уже давно придуман, а в том чтобы узнать о самом существовании алгоритма и реализовать его.

Продолжение подготовки. Фреймворки, инструменты и практики.

После всего этого, ты почти готов пойти на собеседование. Осталось совсем чуть-чуть:

еще раз обрати внимание на коллекции и на сложность поиска в них. Эту тему мусолят все. Не пытайся узнать все подряд: лучше хорошо знать базовые коллекции (ArrayList, LinkedList, HashSet, HashMap, может еще TreeMap), чем знать три десятка, но «по верхам». Т.е. ты должен понимать, как коллекция работает внутри. Есть хороший канал на ютубе, там все разжёвывают для джунов. Прямо так, как тебе и нужно. Вбиваешь в поиск «урок по java коллекции» — первая ссылка на него. Там же есть видео под названием «что нужно знать перед собеседованием». Ты не должен знать прямо все что там перечисляют, ты все-таки джун, на мой взгляд, если ты осилишь 2/3 тем — будет ок.

что такое спринг (тебе нужен Spring Core и Spring Boot) — там понаверчено немало, но 95% практики использования — не сложнее хэловорлда. Ты должен понимать базовые концепции, вроде того что такое IOC и зачем это вообще и уверенно владеть 1-2 способами объявления и инжекции бинов (не xml). Возможно, тебе стоит еще попробовать сделать несколько REST-сервисов на Spring Web: там нет ничего сложного, но будет определенный плюс.
как писать тесты (посмотри на JUnit и Mockito) — в 1Се в принципе нет такой практики как написание тестов. В Java код без тестов — это не код, потому что код считается нерабочим, до тех пор пока нет доказательств обратного.

Когда я говорю «посмотри на [frameworkName]» — я имею в виду: сделать, по крайней мере, несколько домашних проектов с использованием соответствующего инструмента. Скорее всего стоит начать с того, чтобы попробовать каждый фрэймворк отдельно на уровне хэло ворлд, потом стараться собирать их в одном проекте, несущем хоть какую-то «полезность». Кажется неплохой идеей (хотя я так и не делал) — чтобы проекты были как-то привязаны к работе. Может быть просто полностью переписать задачу, которую ты пилишь на 1Се на Джаву, может быть сделать себе какой-то помощник для 1Сной деятельности. Например, если ты пилишь REST обмен с поставщиком на 1Се — реализуй сторону поставщика на Java для тестирования 1Сной функциональности: просто принимай запросы и складывай куда-нибудь.

Все твои домашние проекты должны собираться Maven’ом и версионироваьтся Git’ом. Это просто инструменты, стоит набить руку — и уже перестаешь их замечать. В качестве среды разработки советую тебе взять Idea, по моим наблюдениям ее сейчас используют почти все. Бесплатной версии тебе должно хватить.

Если ты не стеснен в средствах — можешь посетить какие-нибудь курсы по Java разработке. Я считаю, что базовый курс брать не стоит, поскольку все что там будут объяснять не стоит того, чтобы тратить на это время и деньги. Возьми курс по Spring Core или JUnit: с одной стороны ты получишь знания, пообщаешься с будущими коллегами, с другой — тебе не будут 3 дня разжевывать, что такое цикл.

Где-то между делом, надо почитать теорию программирования. Тебя обязательно спросят про SOLID и паттерны. Паттерны (они же шаблоны проектирования) — это весьма интуитивно-понятные вещи, хотя на Википедии описаны так, что чёрт ногу сломит, лучше читать не настольно заумные статьи. На мой взгляд, хватит такого набора: Интерфейс, Билдер, Прототип, Синглтон, Декоратор, Прокси.

Идём на собес!

РаботодателиЕсть несколько основных типов работодателей, о которых тебе стоит знать.

Первый — это бодишоперы. Они же аутстаферы. Самые известные представители: Luxoft и EPAM. Они нанимают людей, а потом перепродают их во всякие Сбербанки. Бодишоперы сажают своих сотрудников прямо в офис заказчика и их почти нельзя отличить от сотрудников заказчика. Зачастую, уровень требований там ниже, а зарплата выше. Но и работать ты будешь в не бог весть каких условиях: это не самые привлекательные проекты, на которые конечный заказчик не смог набрать разрабов с рынка, про трудовой кодекс они будут знать весьма отдаленно, а сам ты не будешь полноправным сотрудником там, где ты будешь работать (всякие плюшки и корпоративы будут проходить мимо тебя). Но тебе же не это надо?

Аутсорсеры — это конторы, которые нанимают конечные заказчики, но предмет продажи там — не люди, как у бодишоперов, а реализация задач. Такие, как правило, стараются держать разрабов подальше от заказчика и занимаются новыми проектами. Это весьма достойное место работы, но туда с таким опытом как у тебя попасть будет не просто, но не невозможно.

Продуктовые компании — это конторы типа Яндекса и, прости господи, Касперского, которые продают свой код как конечный продукт, как коробку. Бытует мнение, что тут работать лучше всего: зарплаты большие, плюшек много, задачи интересные, коллективы профессиональные. Когда ты слышишь про бесплатный английский и пиво по пятницам — скорее всего это про них.

Дальше идут банки и страховые. Тут может быть все сильно по-разному: как правило, в банках есть огромное страшное легаси, на которое никто не хочет идти и новые-модные-стильные-молодежные проекты, на которых вакансии еще как-то закрываются. Сам понимаешь, тебе в первую группу. Хотя, иногда их самомнение может зашкаливать, типа «mission-critical система — не место для джунов». Не обращай на них внимания, такие далеко не все.

Естественно, этот список не описывает полностью всего рынка труда, есть еще всевозможные стартапы, retail и много-много кого.

Во-первых, не надо врать про опыт. Поверь, даже если тебя «случайно» примут за мидла на тех.интервью — в работе ты все равно будешь джуном. Поэтому в резюме не стоит выдумывать, что ты уже работал Java developer’ом 15 лет, пользуясь тем, что в названии твоей предыдущей должности не было упоминания 1С. Но кое-какие ходы, для преодоления HR-барьера, предпринять можно. Не выпячивай свое 1Сное прошлое. На паре последних мест работы можешь написать просто «Программист» или «Developer», а буквы «1С» закопай куда-нибудь в описание. Тим-лида ты этим не проведешь, но HR может купится.

Во-вторых, было бы ошибкой держать твоего будущего работодателя в неведении о том, как ты занимался самоподготовкой. Напиши полгода подготовки как отдельное место работы (оно должно быть в самом верху), с пересечением по сроку с последним местом работы. Назови это «Java developer», место работы — «самоподготовка» или «домашние проекты» и перечисли технологии, которые ты попробовал. Дай ссылку на профиль на хакерранке.

В-третьих, придумай убедительную причину почему ты хочешь в Джаву. Не советую говорить «надоело нянчиться с бухгалтерами» или «не хочу, чтобы моя зарплата обрушилась вместе с курсом рубля» и тем более «хочу свалить из этой грё…». Лучше всего заходит тема с развитием: мол, там уже все повидал — надо двигаться дальше.

В-четвертых: ты джун и таких как ты, каждый год из институтов выпускают сильно больше, чем есть вакансий джунов. При этом те, кто из институтов — без семьи и детей и готовы жить на работе и жить работой и им не надо платить ипотеку. Ок, на твоей стороне опыт, но это не релевантный опыт и его не будут рассматривать как большую ценность. Из этого следует, что тебе нельзя задирать ожидаемую зп. Если ты не можешь прожить на зарплату джуна — подрабатывать 1Сником на четверть ставки — неплохой вариант на первый год.

Ходи по собесам, запоминай вопросы, находи на них ответы, затем опять ходи по собесам. На мой взгляд, 1-2 тех.интервью в неделю — приемлемый уровень, чтобы и успевать переваривать полученный опыт и не слишком затягивать поиски.

Работа джуном

Самое важное тут — это Тим лид. Ты должен был познакомиться с ним на тех.собесе и «он должен был выбрать тебя и ты должен был выбрать его» (с). Очень важно почувствовать эту химию. Это человек, каждое слово которого в следующие несколько лет, ты должен слушать, запоминать и выполнять. Этот человек будет тащить тебя к вершинам Java разработки и посвящать тебя в самые глубокие нюансы этой магии. И от него, может быть даже больше чем от тебя самого, зависит, насколько крутым разрабом ты станешь и как скоро.

Итак, мой юный 1С-ник, если раньше ты знал «зачем?», то теперь еще знаешь «как?». Путь в тысячу миль начинается с одного шага. Дерзай!

Устроиться работать джавистом быстро и без проблем

Чтобы устроиться джавистом, одного знания Java мало. Это лишь 10% того, что вам нужно знать, и сейчас мы разберемся с оставшимися 90%.

Мы собрали распространенные IDE, фреймворки, некоторые «фишки» по ООП в целом, а также подкрепили все полезным материалом в виде ссылок. Тем не менее, если вы посчитаете статью неполной, обязательно поделитесь своими соображениями в комментариях к ней: данная информация поможет тем, кто начал свой путь развития в области кодинга на языке Java.

Все начнется с ООП. Это альфа и омега всех вопросов, которые затрагивают объектно-ориентированные языки программирования. Готовьтесь и к банальным вопросам из разряда «3 (а то и 4) принципа ООП», и к задачкам посложнее, например, объяснить, что происходит в коде, написанном на гипотетическом языке программирования.

Нередко звучат вопросы о принципах ООП, модификаторах доступа, коллекциях, etc. Но самое интересное начинается лишь тогда, когда вы переходите непосредственно к ЯП.

Java изобилует библиотеками, которые предоставляют больше гибкости, но споткнуться можно и о Java Core. Вот лишь малая толика вопросов по данному языку:

Что произойдет, если при переопределении equals() не переопределить hashCode()?
Почему метод clone объявляется как protected?
В чем разница между final, finally и finalize()? Расскажите, что это такое.
Что случится, если единственный конструктор класса будет объявлен как final?
Расскажите про все методы класса Object.
В чем отличие между equals() и ==?
Абстрактный класс и интерфейс: есть ли разница?
Когда лучше применять ArrayList, а когда – LinkedList?

И так до бесконечности. Чтобы стать хотя бы джавистом стажером, нужно хорошо знать Java Core. Зато когда вы поймете все тонкости этого языка, можно смело переходить к изучению фреймворков.

Это обязательно. Если у вас все очень плохо – запишитесь на курсы. Если все нормально, но хотелось бы лучше – английские сериалы с субтитрами в помощь.

Не думайте, что он нужен только для умения прочесть что-то вроде «toString» или «valueOf». Документация, различные проблемы, решения которых давно заждались вас на Stack Overflow, полезные англоязычные материалы – это все действительно пригодится.

Но работодатель в первую очередь хочет, чтобы вы могли свободно общаться с иностранными коллегами. В общем, даже если ваша работа мечты находится в Германии, прежде чем научиться «Deutsch zu sprechen», освойте английский: это один из столпов IT-сферы, без которого вам не стать джавистом.

IntelliJ IDEA – всеми любимая, удобная, «ламповая» среда разработки. Но очень вредная, особенно для начинающего программиста. Привыкнув к «легкому» коду в IntelliJ IDEA, можно навсегда возненавидеть NetBeans и Eclipse (а опыт работы с последней IDE требуют отнюдь не редко).

Начали с IntelliJ? Что ж, постарайтесь «переломать пальцы» под Eclipse: это полезный опыт как для пользователя данной IDE, так и для программиста в целом. Но вообще, идеально, если вы освоите все 3 IDE: резюме расширит и в жизни пригодится. Параллельно учите хоткеи, с которыми написание/тестирование кода и отладка станут ускоренными.

Появился Docker, и все как-то сразу стало проще, но знание MacOS и/или Ubuntu все еще в приоритете, если хотите стать джавистом. Работать с ними легче и приятнее за счет нативной консоли с соответствующими командами. Стоит ли отмечать, что не под Windows все зачастую летает, а бесплатная операционная система – вообще на вес золота (нет, в компаниях пиратками не пользуются: либо лицензионка, либо свободная ОС)?

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

Подавляющее большинство компаний делает упор на знание MySQL – универсального инструмента для работы с базами данных. Но знание – не значит однодневный опыт или «Да, я с этим когда-то сталкивался». Вы должны действительно понимать запросы и уметь оптимизировать структуру. Сложно? Начните хотя бы просто с установки СУБД и изучения CRUD (создать, прочесть, обновить, удалить).

Порой могут потребоваться знания PostgreSQL, MongoDB, SQLite, Redis, etc.

HTML станет хорошим помощником в работе с сервлетами, GUI и не только. Java все еще используется в вебе, в сложных архитектурах, где приоритетнее стабильность работы. Правда, это уже больше относится к серверной части. Но все равно знание языка гипертекстовой разметки лишним точно не будет. Подробнее о HTML можно почитать здесь, а больше полезных материалов для его изучения найдете в данной статье.

Формат данных XML – вечный спутник парсинга и лог файлов. Умение работать с XML не критично, если обратное не заявлено в требованиях, зато покажет вас как программиста с лучшей стороны.

А вот JSON расшифровывается как JavaScript Object Notation. В отличие от XML, это компактный текстовый формат обмена данными, и он предназначен для легкого восприятия человеком. Часто используется при обмене информацией между сервером и веб-браузером. Интернет изобилует материалами о JSON, так что вы быстро поймете принципы работы с ним.

Spring MVC – лидер современного рейтинга. Чтобы стать джавистом в большинстве компаний, требуется знание данного фреймворка. Главная причина – его универсальность. Грубо говоря, это целый набор фреймворков, которые позволяют решать различные задачи.

В JSF все немного иначе, и основная его фишка во взаимодействии с компонентами. Есть поддержка Oracle, уйма дополнительных инструментов, дружелюбное комьюнити и «человеческая» документация.

Vaadin также ориентирован на веб-разработку. Его главное преимущество состоит в работе без необходимости прикручивать дополнительные web-языки, такие как JS, XML, HTML. Здесь хорошо реализованы MVP и MVC. В вакансиях встречается реже перечисленных фреймворков, но порой требуется.

Да, чтобы быть джавистом, нужно думать как джавист.

Часто это работа в команде, и такой скилл, как чтение чужого кода, обязательно учитывается. Если данный опыт есть – указывайте его в резюме и рассказывайте о нем на собеседовании. В противном случае постарайтесь открыть для себя Open Source и вливайтесь в командную разработку. Умение работать с чужим кодом не менее важно, чем знание самого языка: это покажет, что вы разбираетесь не только в своем стиле, но вполне можете «адаптироваться» под другие.

Будьте общительны. Обретая коммуникативные навыки и расширяя круг общения, вы набираете полезные контакты и новые знания. Активно участвуйте в собеседованиях, не замыкаясь в себе после очередного «провала».
Не засиживайтесь на одном месте. Меняйте работу, если в текущей компании повышение даже не светит. Это актуально для всех, в т. ч. для начинающих программистов, которые боятся потерять свое первое рабочее место: всегда лучше двигаться вперед.
Продолжайте учиться. Открывая для себя новые отрасли, технологии и фреймворки, вы дарите себе уйму возможностей пробиться дальше.
Умейте себя продать. Когда дело касается озвучивания желаемой заработной платы, многие банально стесняются, даже если это стеснение лишает половины того, что они могли бы получать. Здраво оценивайте свои силы и не бойтесь заявить о желаемом уровне зарплаты работодателю.
Посещайте семинары, хакатоны и прочие мероприятия, нацеленные на оттачивание навыков.
Читайте книги, пользуйтесь сервисами и решайте задачки (можно просто отвечать на вопросы Stack Overflow).
Отдавайте предпочтение валюте, работая на иностранные компании. Можете вообще переехать в другую страну, если хорошо владеете английским, и ваши навыки соответствуют заявленным в вакансии.

Где найти опыт работы для новичка в программировании на Java? — Хабр Q&A

Хотелось бы узнать подробнее про то, где находить опыт работы. Полазил по интернетам вашим и выделил некоторые варианты.
1) Open Source. Так как я новичок, то просто вбил в гугле «опен сорс проекты java». Получил много ссылочек, но очень старых. А по сортировке «за последнюю неделю» тоже ничего. Возможно я глуповат. Но также слышал, что новичкам не надо лезть сюда, так как Open Source не для новичков
2) Создать свой проект, который будет полезен людям и который будет приносить деньги.
Может у меня скудная фантазия, но я ничего подобного не могу придумать. Ощущение, что либо это уже было, либо это слишком просто, либо не нужно. Можете хотя бы привести пример того, что можно сделать своими руками новичку, чтобы это было полезно. Хотелось бы хотя бы представлять масштабы работы. Месяц, полгода, год (про неделю не стал писать, так как для такого, что нужно будет людям, ощущение, что это слишком малое время)…
3) Идти на стажировку. В принципе я не против. Но вакансий на стажировку слишком уж мало да и зачастую там еще параллельно надо знать Python, Ruby и еще целую гору всего (Санкт-Петербург на сайте hh). Я блин готов за бесплатно работать, лишь бы опыт шел. И готов учить и другие языки, но если бы это уже было на уровне хотя бы Junior. (про гору всего не относится к js html css spring и пр. что требуется от java разработчика и так практически везде. это все надо знать, я в курсе. но вот Ruby…)
Если следовать логике, что нужен опыт разработки, то, теоретически, подошла бы любая программа, если бы я в ней использовал паттерны и различные технологии, чтобы показать, что я что-то понимаю. Но вокруг слышу только одно — программа твоя должна быть нужна.
P.S. реально вспотел, пока придумывал суть вопроса, которая заканчивается на знак вопроса.

Вопрос задан более двух лет назад
1997 просмотров

Мой путь программиста. От студента-QA до удаленного Java-разработчика / Habr

Привет Хабр! В этой статье я хочу рассказать о своем пути в области IT. На данный момент он занял у меня уже 6 лет, и еще отнюдь не завершен. Я начинал как QA инженер еще будучи студентом, а сейчас я работаю удаленно через Upwork на довольно крупную американскую компанию. Нет смысла указывать конкретные компании, в которых я работал, поэтому все названия будут в стиле “вот эта вот” и “другая”.

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

Этап 1: QA Engineer

Я начал работать QA инженером (пишу именно это умное слово, а не “тестировщик”, поскольку в трудовой стоит именно эта запись) летом 2010 года, тогда я перешел на 4й курс университета. Университет весьма уважаемый, впрочем, это не имеет значения.

Я твердо решил стать разработчиком, когда мне было лет 12. Тогда у меня еще не было компьютера, но была замечательная приставка СЮБОР, позволяющая писать простейшие программы. Но спустя 8 лет я стал тестировщиком… то есть, простите, QA инженером. Дело в том, что мне поначалу довольно тяжело давалось программирование, и я не мог схватить как следует идею ООП, да и с функциональным программированием у меня было тоже довольно посредственно.

Итак, я устроился по профилю, довольно близкому к разработке, и это меня утешало. К тому же, мануальным тестированием я занимался крайне мало, потому что мой лид практически сразу решил меня бросить на авто-тестирование. Спасибо ему большое за это! Я писал авто-тесты на Selenium WebDriver, используя Java. В процессе написания скриптов я познакомился с такими штуками, как JUnit и Eclipse. А параллельно почитывал книжку по Java – довольно хреновую, но определенные знания я все же почерпнул из нее.

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

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

Еще полгода я занимался саморазвитием. Я вышел на разговор еще раз, а параллельно сходил на собеседование в другую компанию. И – мои труды были вознаграждены! Ребята с проекта сказали, что я сильно вырос, и что, вероятно, смогу перевестись в разработчики через месяц. А еще через неделю мне позвонили из другой компании и поздравили – ведь они готовы взять меня на позицию Junior iOS Developer! До сих пор для меня загадка, почему именно iOS, ведь я собеседовался на Java и отвечал на соответствующие вопросы. Но знаете, что я сделал? Я отказался, ведь меня должны были перевести в разработчики уже через 3 недели!

Конечно, никуда меня не перевели. Примерно в это время я пошел на курсы Java-разработчиков в третью компанию, а через 3 месяца уволился. Курсы должны были закончиться спустя 2 месяца после моего увольнения, но я верил в то, что меня, как одного из лучших студентов, возьмут в штат. И не зря.

Вывод: вы обязательно добьетесь того, чего действительно хотите. Нельзя довольствоваться посредственностью. (Забегая вперед – не рекомендую также находиться в зоне комфорта слишком долго. Только покидая зону комфорта, можно достичь новых высот – об этом ближе к концу)

Этап 2: Java Developer

Да, меня взяли разработчиком летом 2012. Поначалу это была практически эйфория – ведь я теперь буду разрабатывать, и совсем-совсем не буду заниматься неинтересным мне тестированием! Мне нравилось это время.

Сразу по приходу в компанию я попал на бенч, потому что компания не смогла сразу же определить меня на проект. На бенче я сидел около двух недель – в это время я занимался простеньким учебным проектом, где я мельком познакомился со Struts2 и Mercurial. Затем мне написал мой Resource Manager с радостной новостью, что меня готовы рассмотреть на настоящий, боевой проект! Там уже работал ведущий разработчик, и ему требовался смышленый товарищ, но желательно уровнем повыше, чем junior. И еще здесь была ужасная деталь – мне необходимо было пройти собеседование по скайпу с человеком из Москвы! Наверное, как и большинство неопытных новичков, я паниковал от одной только мысли о собеседовании (это сейчас мы рассматриваем это как приятное времяпровождение, где можно выявить пробелы в знаниях, верно?). Буду краток – собеседование я прошел неплохо, и даже написал Ping Pong на двух потоках в качестве тестового задания. Параллельно со мной собеседовали еще одного разработчика с бенча, но в итоге предпочтение отдали мне. Скрывать не стану – мне было очень приятно, особенно на фоне новости, что хотели брать хоть сколько-нибудь опытного человека.

Поначалу для меня было все в новинку – ant, SVN, JDBC, ну и конечно же Java Core. Всего было так много, что я решил даже не заниматься дополнительно, ведь итак много всего изучал каждый ~~божий~~ рабочий день. В итоге я более-менее научился пользоваться некоторыми инструментами, но не имел четкого понимания, как именно они работают. Вследствие этого довольно часто я изобретал велосипед и усложнял вещи.

Совет: всегда досконально изучайте то, с чем имеете дело. Знание деталей поможет вам писать более эффективный и лаконичный код. Многие скажут, что для того, чтобы водить машину, необязательно знать устройство двигателя. Скажу лишь то, что это довольно бредовая аналогия, и что для меня разработчик – это не водитель, а механик. А вот ему уже все-таки надо знать хоть чуть-чуть, верно? Задача плохого разработчика – сделать, чтобы работало. Задача хорошего разработчика – чтобы работало эффективно. (Задача совсем хорошего разработчика – чтобы еще и код было приятно читать).

Около года я проработал на этом проекте. Я помню, что офис находился далеко от дома, и я решил ездить на работу к 7:30 утра по следующим причинам:

Не попасть в пробки
Успеть занять место на парковке
Мой лид приходил часам к 11. Следовательно, до 11 я мог читать книги по джаве – такой был мой план.

В это время я прочитал книгу Брюса Эккеля “Философия Java” и первый том книги по Java Кея Хорстмана и Гари Корнелла. Честно говоря, чтение давалось с трудом. Думаю, это из-за того, что я не до конца представлял, что произойдет после того, как я их дочитаю. Я не особо представлял себе свое будущее, были лишь размытые цели типа “стать хорошим разработчиком”.

Совет: всегда ставьте цель при прочтении книги. Прямо так и спросите себя: “А зачем я читаю эту книгу? Что я хочу узнать после ее прочтения? Как мне это поможет?”. Простое чтение быстро становится рутиной, которой заниматься хочется все меньше со временем.

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

Мы туда попали вдвоем с другом, с которым вместе ходили на курсы. Это плюс. Единственный.
Сами мы занимались правками JSP страничек и Struts классов. А на стороне ABAP сидел лодырь, правки от которого мы могли ждать часами. Простейшие правки.
JSP странички содержали практически всю логику приложения.
Отвратительное подобие менеджера проекта, который раз в неделю появлялся в скайпе и спрашивал: “Ну как, все хорошо?”. Следовательно, все проблемы с заказчиком мы решали сами.
Невозможно было сразу увидеть результаты своих правок. А деплой мог тоже длиться часами, к тому же деплои нужно было согласовывать.

Проект длился всего 2 месяца, но мы успели почерпнуть массу эмоций.

И вот, где-то в 2013 году, я попал на уже настоящий Enterprise. Там я познакомился с Maven и рядом продуктов IBM: WebSphere, RAD, DB2. Что мне особенно понравилось, так это то, что я плотнее познакомился с JavaScript и jQuery (тогда его еще вроде как использовали). А еще там был очень суровый самописный аналог Hibernate. Это объяснялось тем, что Hibernate “тормоз”, а нам нужен был реактивный механизм ORM, который мгновенно положит записи в базу и заберет их оттуда. Не сказать бы, что я с этим согласен, но на тот момент это вполне могло иметь смысл – система имела миллионы запросов ежедневно, поэтому дело осталось за JDBC (если вы не из мира Java, то JDBC – это Java DataBase Connectivity, просто механизм взаимодействия с базой без каких-либо преобразований записей БД в объекты).

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

Этап 3: Смена работы и свои проекты

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

Пропуская мелочи – я устроился в ужасную компанию, но на более высокий оклад и другие технологии. Хочу выписать основные минусы:

Собеседование. Меня собеседовали не в переговорке, а в обычном кабинете, где сидели и работали люди. Думаю, это напрягало не только меня.
Переработки. Я пришел как раз в период аврала, и спустя 3 рабочих недели мне пришлось целый месяц выходить по выходным. За это я получил компенсацию за полтора рабочих дня по ставке один к одному с формулировкой: “Ну ты же ничего полезного особо не сделал, проект не знаешь еще”
Процессы. Точнее их отсутствие. У нас была Jira, но ей никто не пользовался. Активности отмечались в гуглодоке, а задачи ставились либо по скайпу, либо менеджером по телефону. Само собой, все всегда забывалось, и что-то не делалось или делалось не так.
Отвратительный офис с маленькой кухней, сделанной из комнаты, и общим на этаж туалетом.
Требование появляться в офисе в 10 утра. Жутко неудобно, так как по утрам я люблю заниматься спортом. Конечно, можно вставать пораньше, но это уже я не люблю.
Все мои предложения по улучшению процессов не возымели эффекта.
Учиться было особо не у кого – не было действительно сильных разработчиков.

Чем дольше я работал, тем отчетливее понимал, что этот этап будет недолгим. На этом проекте я познакомился с GWT, Spring и более плотно поработал с Hibernate. Собственно, GWT мне очень не понравился, я посчитал его абсолютно недееспособным на фоне современных инструментов. Ну, и дополнительно изучать GWT я тоже не стал. Оговорю сразу, что это лишь мое впечатление от столкновения с ним.

Зато в это время у меня появился общий с друзьями небольшой проект. Проект был довольно простенький, но все же было интересно его проектировать и реализовывать. Я ближе познакомился с JavaScript, Spring, Hibernate и JUnit.

В этот период я начал читать книги не столько технические, сколько по написанию кода в целом. Во многом я проникся книгой “Чистый Код” дядюшки Боба.

Констатация факта: на определенном этапе приходит осознание того, что нужно знать не только используемые технологии, но и правила написания хорошего кода в целом – структура, архитектура, рефакторинг и конечно же тесты.

Спустя 9 месяцев после смены работы я уже отчетливо понимал, что текущее место сильно тянет меня вниз, поэтому решил вернуться на предыдущее место работы. Естественно, на еще чуть больший оклад и интересный проект.

Совет: если имеется довольно сильный дискомфорт в работе, то не нужно бояться положить этому конец. Пусть даже ценой смены рабочего места. В конце концов, в этом нет ничего страшного. Соглашение изначально полагается как взаимовыгодное, и если вам оно невыгодно – исправляйте ситуацию.

P.S.: без фанатизма. Я не пропагандирую идею прыгать с места на место в попытках поднять свою позицию и оклад. Прежде всего, нужно постоянно чему-то учиться и применять знания во благо компании. Но если вы ощущаете, что застаиваетесь, что ваши знания не востребованы или что на вас ездят – тогда перечитайте совет выше.

Этап 4: Возвращение на родину

Итак, я вернулся в ту компанию, которая дала мне старт как разработчику. Мне попался довольно крупный проект с Big Data, и мы использовали вполне современный стек: Spring, Hadoop (и его экосистема: HBase, Oozie etc), Maven, TestNG. Вероятно, многие посчитают Hadoop уже не таким современным, но это не умаляет современности самого направления. А еще именно тогда я познакомился со Slack и очень оценил этот инструмент.

Наш проект состоял из менеджера и двух Java-разработчиков в нашем офисе, а также менеджера и Java-разработчика в США. Вернувшись, я сразу почувствовал всю разницу между хорошими процессами и их отсутствием:

Мы использовали Jira и работали по Agile.
У нас были действительно короткие стендапы по утрам и не было затянутых нудных коллов.
Было чему поучиться у второго разработчика в нашем офисе.
Адекватные код-ревью.
3 раза в неделю у нас были короткие созвоны, где менеджер предоставлял нам краткую выжимку того, что происходит в компании и на соседних проектах, а также планы по проекту.

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

Я внезапно почувствовал острое желание работать ближе к клиенту, возможно даже заняться front-end. Мне начало жутко надоедать работать с Big Data. Мне надоело ходить через несколько удаленных рабочих столов на сервер. Мне надоело запускать свой Job и затем подолгу копаться в логах и анализировать их. Ни в коем случае не назову это скучной и нудной работой, но что-то изменилось. То, что поначалу показалось весьма новым и интересным, спустя время начало надоедать и становиться рутиной. Я пошел к начальству и честно все сказал: я хотел попробовать front-end. А параллельно с этим отправил “шальное” резюме на случайно увиденную, но очень интересную вакансию.

Руководство снова выслушало меня и обещало подумать. А я в это время сходил на собеседование и получил тестовое задание. И, скажу честно, тут я начал метаться. С одной стороны, вакансия была очень заманчивой, а с другой – не хотелось уходить из хорошей компании, которая мне доверяла, спустя полгода после возвращения. На тестовое задание выделялось 2 недели, но я тянул месяц. В конце концов меня позвали на второе собеседование и сделали оффер.

Если кратко – я принял предложение, после чего меня ожидал неприятный разговор с RM. Неприятный потому, что, как я и предполагал, я услышал что-то вроде “как тебе доверять после таких поступков”. Но я решил не принимать это близко к сердцу, ведь за эти полгода я принес компании определенную прибыль, да и проекту помог. Забегая вперед – я не жалею об этом.

Совет: еще раз – вы никому ничего не должны. Если есть возможность – не упускайте ее. Это ваше развитие. Но отнеситесь с пониманием к работодателю – сделайте все возможное, чтобы ваш уход не сказался на проекте. Работайте усердно в эти последние 2 недели и закройте все свои задачи, создайте документацию по вашим наработкам, если еще этого не сделали. Посоветуйте кого-нибудь на ваше место. Но возможность не упускайте.

Этап 5: RoR Developer

Да. Я начал писать на Ruby on Rails. Не буду подробно писать о процессе изучения нового языка, лишь самое главное:

Меня практически сразу бросили на боевой проект
Коллега по проекту, также бывший Java-разработчик, активно помогал и рассказывал об особенностях языка
Руководитель направления также весьма активно участвовал в моем развитии и обучении
Я прочел документацию и несколько книг по теме

Как видно, в этой компании все было весьма неплохо. Где-то полгода мне потребовалось, чтобы перестать испытывать какие-либо сложности в процессе написания кода. Еще полгода потребовалось, чтобы лучше изучить тонкости языка и начать писать по Rails Way.

Итак, поздняя осень 2015. Я уже полгода работал в новой компании, зарплаты хватало на все, проект хоть и не самый интересный, но для меня было много нового, следовательно я не скучал. На проекте я познакомился со множеством интересных инструментов: некоторые сервисы Amazon, Heroku, rspec и множество гемов для rails. Но самое главное – я пощупал динамический язык программирования. И если поначалу было абсолютно ничего не понятно, то спустя полгода началась эйфория от этой магии. А потом снова стало непонятно.

Мнение: динамические языки это очень круто. Можно буквально в одну строку писать мета-код, который на лету напишет другой код, который сделает кучу работы. ActiveRecord – круто. С другой стороны, когда эйфория прошла и настали серые будни, эта магия начала нравиться все меньше. Временами код было тяжело читать и неудобно дебажить. В конце концов я пришел к выводу, что лично мне статические языки нравятся больше, на них приятнее писать. Хотя, дело лишь в прямых руках, которые я не до конца успел отрастить за год работы на RoR.

Итак, прошло полгода, как я пишу на Ruby on Rails. Примерно в это время я заинтересовался Upwork. Но заказ я нашел на JavaFX и занимался им около месяца по 10-20 часов в неделю. Понравилось, но график 40 + 10(20) начал утомлять, поэтому после окончания проекта я решил отдохнуть от Upwork пару месяцев.

Затем я нашел другой проект, уже на Ruby on Rails. Ставка была $25/h, а также было условие: работа fulltime. Длительность – от месяца до трех. Если кратко – я работал месяц, дальше проект свернулся по причине стартапа. Это было очень тяжело – первую неделю я отработал все 40 часов вдобавок к тем 40 на основной работе. Далее я работал 35, 30 и 25 часов во вторую, третью и четвертую недели соответственно. Это настолько меня утомило, что я решил еще несколько месяцев отдохнуть от дополнительных проектов. Хотя, стоит отметить, заработал я вполне неплохо за это время.

Итак, я решил сосредоточиться на основной работе, а по вечерам отдыхать либо заниматься самообразованием, а не работать на другой. Некоторое время продолжался такой режим – я не перенапрягался, изучал новое и жил спокойно. А затем проект отдали индусам, а меня кинули на… наидревнейший проект на старых Ruby и со старой легаси-системой, которую мы поддерживали. Видимо, это мой рок – работать на старых проектах. Вдобавок к этому я начал все отчетливее видеть косяки в процессах компании, на которые не обращал внимания поначалу. Основные из них: скудный набор проектов и полнейшее отсутствие аналитики, а также отсутствие тестировщика на проекте.

Совет: если в вакансии в разделе “ожидаем от соискателя” фигурирует пункт “умение работать, не имея законченных требований”, то лучше знайте перевод: “У нас в компании нет аналитики, поэтому ее следует провести вам. И реализовать задачу потом тоже по своим же требованиям”.

Помните, я говорил, что только покидая зону комфорта, можно достичь новых высот? Работая на данной работе, я получал хорошую зарплату, меня устраивал коллектив и офис. В целом было комфортно, и я мог бы остаться на том проекте, особенно если учесть, что загрузка по нему не была полной. Я мог читать статьи и даже заниматься личными проектами в свободное время. Но какое развитие я получал, кроме своих личных начинаний? Как текущее рабочее место способствовало моему развитию? На одном изучении далеко не уедешь, нужна практика. И практика нужна не только в свободное время, но и в каждодневной работе.

Я решил вплотную заняться Upwork.

Этап 6: Fulltime на Upwork

Я немного поискал и нашел подходящую мне работу. Это long-term сотрудничество с довольно крупной американской компанией. Первые 3 недели я работал параллельно на двух работах, а уволился лишь после того, как получил email с указанием того, что работодатель очень доволен качеством моей работы, и классным задачам и морю веселья для меня не будет конца.

На данный момент я работаю здесь чуть более 2 месяцев, и пока что меня все устраивает: стек, процессы и коллектив. Западный стиль управления мне нравится больше. Мне нравится слышать слова “amazing”, “fantastic”, “awesome” при оценке моей работы. Само собой, со своей стороны я тоже прикладываю максимум усилий, чтобы услышать эти слова.

Я не буду описывать, как найти работу на Upwork – на хабре полно статей на эту тему. Опишу основные, наиболее важные моменты на мой взгляд:

Заполнение вашего профиля очень важно. Это то, что работодатель увидит во вторую очередь.
Конечно, хорошо пройденные тесты вам на руку.
Cover letter крайне важно. Это то, что работодатель увидит в первую очередь. Укажите, кто вы и откуда, какой у вас часовой пояс, и готовы ли вы работать по бизнес-часам работодателя, хотя бы частично. Укажите свой опыт и стек, а также дайте понять, что вы хорошо знакомы со стеком работодателя. Не врите. Скиньте свой профиль на linkedin/github/stackoverflow. Если вы только начинаете и у вас пока нет репутации на Upwork – можете указать о готовности выполнить тестовое задание на пару часов.
Портфолио также будет отнюдь не лишним.
Работайте только с работодателями, у которых рейтинг стремится к 5 звездам. Читайте отзывы. Помните, что неадекватный клиент может подпортить вашу репутацию.
Кто-то рекомендует хвататься поначалу за любые заказы, будь то даже пятидолларовый фикс-прайс. Я не думаю, что выполнение дешевых заказов красит вас как опытного разработчика, поэтому я изначально брался только за почасовые заказы с прайсом не менее $20/h.
Избегайте «евреев».

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

– Эта задача может быть выполнена быстрее, чем за 12 часов. Я заплачу только за 10.
– Если вы меня наняли, то извольте руководствоваться моими оценками. Я очень подробно описал, почему это займет именно 12 часов.
– Я работал в прошлом разработчиком и кое-что понимаю. К тому же, я не согласен с тем часом, который вы выделили на риски. Его можно исключить.
– Эти часы нельзя исключать из эстимейта, так как мне необходимо поддерживать старый код – в процессе внедрения фичи что-то может пойти не так.
– Артем, вы же профессионал и должны понимать, что это бизнес – я плачу только за фактически выполненную работу, а не за ваши часы.
– Во-первых, ваш бизнес меня не касается. Вы тоже профессионал и должны понимать, что вы вкладываете деньги не только в фактически выполненную работу, но и в знание проекта разработчиком, который будет его поддерживать. Если я потрачу 12 часов на выполнение задачи, я буду ожидать оплату за 12 часов. Если потрачу 8 – оплатите мне 8 часов. Иными словами, я ожидаю оплату за все время, что я потрачу на ваши проекты. Во-вторых, у нас была договоренность о почасовой работе, а текущее развитие событий меня не устраивает.
– Хорошо, пожалуйста сделайте коммит всего, что у вас есть. Я найду другого разработчика.

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

Позволю себе отойти от лирики и опишу основные плюсы, которые я вижу на текущем рабочем месте:

Укомплектованная команда: аналитика, разработка, QA, devops.
Работа по спринтам с четкой постановкой задач.
Заработная плата в 3,5 раза выше, чем на прошлом рабочем месте.
Работа из дома – для меня это плюс, так как не испытываю проблем с самомотивацией и дисциплиной.

Если честно, я не знаю, как долго небо над головой будет безоблачным. С одной стороны, работа в России в соответствии с ТК РФ выглядит надежнее. С другой стороны, пары месяцев работы удаленно хватит для создания очень комфортной подушки безопасности. На данный момент ничего не предвещает беды, работодатель имеет большой скоуп задач на много месяцев вперед, а моя работа его вполне устраивает. А еще с каждой неделей растет моя репутация на Upwork, так что я смею надеяться, что в случае необходимости я найду новую работу довольно быстро. Также добавлю, что я работаю строго по ТК РФ – я зарегистрировал ИП и плачу налоги.

Совет: не торопитесь. Суммарно за 4 проекта на Upwork я видел немало ужасного кода. Люди часто уходят на вольные поля, не получив достаточного количества опыта. Их банально никто не тыкает носом в их косяки и не говорит, как надо это делать правильно. Мой путь пока что занял у меня 6 лет, из которых 4 я посвятил разработке и постоянному самообразованию. 80% времени мной повелевали опытные и мудрые тимлиды, которые передавали мне частичку своего опыта. Не торопитесь уходить во фриланс/удаленную работу.

Заключение

Да, 6 лет – это немного. Но все же довольно длинный путь уже пройден. Я не жалею ни об одном своем шаге на протяжении этого пути. По большей части, эта статья – просто мои воспоминания и выписка основных моментов. А все советы, которые я позволил себе озвучить – это те советы, которые я дал бы самому себе, если бы мог. Но, тем не менее, я буду очень рад, если это подобие мемуаров кому-то поможет или вдохновит на что-то. Успехов!

Большая подборка книг, видео и статей для Java Middle

Java Middle – это соль земли от мира информационных технологий. В статье самые полезные материалы, которые помогут прокачать навыки.

Помните правило Парето? Так вот, Middle-разработчики – это люди, которые сделали те самые 20% усилий, и теперь имеют 80% результата. Это не переджуниоры и не недосеньоры. Это отдельная категория программистов.

Что должен знать Java Middle программист?

Начать нужно с анализа требований к мидлу. Для этого подойдет семинар от Александра Марченко. Тут хорошо разграничены требования к Middle и Junior. По-крайней мере, с наиболее распространенной точки зрения. Для самопроверки полезно познакомиться с рынком: посмотреть на требования в вакансиях Java Middle и походить на собеседования.

Фреймворки

Очевидно, что Java Middle-разработчики используют какой-либо фреймворк. Например, Spring или что-то из Java EE. Полезно иметь свой pet project на непривычном для себя стеке и прокачиваться в нем.

Есть два шикарных канала, каждый из которых посвящен одному из этих фреймворков.

Spring

Микросервисы, SpringOne, облачные решения и многое другое в формате лекций, вебинаров и proof-of-concept-ов от лучших зарубежных разработчиков, команды SpringSourceDev.

Java EE

Канал от разработчика Adam Bien, который, согласно его блогу, является Java Champion, NetBeans Dream Team Founding Member, Oracle ACE Director, Java Developer of the Year 2010. Человек фрилансит на стеках Java EE с 1995-го года и до сих пор не уехал кукухой. Заслуживает уважения, тем более что и материал на его канале емкий и наглядный. Адам демонстрирует в формате скринкастов, каким симпатичным и легким для понимания может быть код на Java EE.

Hibernate и JPA

Взаимодействие с данными – важная область, в которой постоянно будет вариться любой Java Middle. Канал «Thoughts of Java» несколько раз в неделю публикует короткие видео. В каждом дается готовый рецепт по той или иной проблеме, связанной с persistence level вашего приложения. Как мапить “Y” и “N” в булевы значения в БД? Как запилить кастомный генератор идентификаторов? Можно ли распарсить EntityGraph из строкового представления? Все это и многое другое расширит опыт и пополнит ваш арсенал программиста трюками на каждый день.

Конференции

Чтобы постоянно качать свой скилл в программировании, нужно держать руку на пульсе. В этом помогут конференции. Они исключительно полезны и как источник знаний, и как компас в мире языка Java. Разработчик, который смотрит исключительно в свой проект, открытый в IDE на рабочем компьютере – умирает как профессионал.

Есть также хорошие зарубежные каналы такой же тематики, один из лучших – Devoxxx.

Как привести дела в порядок – Дэвид Аллен

Наша подборка для Java Middle начинается не с технической книги, а с классики тайм-менеджмента. Это неслучайно. На мидлов ложатся непривычные для них ранее обязанности, а справляться с ними они еще не привыкли. Поэтому создается лишний стресс, который легко может разрушить work-life баланс и привести к выгоранию.

Какой смысл в любых знаниях и навыках, если вы только и будете залипать в монитор, искать мотивацию и бороться с усталостью? Чтобы не столкнуться с выгоранием, нужно осваивать дисциплину и эффективно организовывать работу. К счастью, это обычная наука, такая же, как программирование. И эта книга поможет стартовать в нужном направлении.

Приемы объектно-ориентированного проектирования. Паттерны проектирования. – Гамма Э., Хелм Р., Джонсон Р., Влиссидес Дж.

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

Мифический человеко-месяц – Фредерик Брукс

Библия программной инженерии, книга от опытнейшего разработчика компании IBM. В ней в виде очерков раскрываются важные нюансы управления проектами. Это как «Совершенный код» Макконнела, только про проекты. И это куда важнее кода. Мидл-программист должен уметь трезво смотреть на окружение, в котором он работает. Потому что понимание процессов и проблем, с которыми сталкиваются команды разработчиков каждый день, позволит генерировать правильные идеи и стать ценным сотрудником.

Книги по сертификации

Сертификация Oracle – важный майлстоун для каждого Java Middle developer’а. Не потому, что важна какая-то корочка. На самом деле на нее редко кто смотрит, это скорее имиджевая штука. Хотя, бывает, без нее и на крутой проект не попасть. Но крайне редко.

Просто важно уметь аккумулировать знания и получать их объективную оценку. Да и книги, посвященные подготовке к сертификации, раскрывают важные нюансы Java Core. Ещё они предлагают практику в виде примеров тестов с разбором ошибок. На таком стыке углубленной теории и интересной практики изучение Java пойдет как по маслу. Ну и бумажку красивую получите, заламинируете и маме покажете 🙂

Книги: по Java 6, по Java 7, по Java 8

Многопоточность

Если вы Java Middle и конкретно встряли, то встряли вы на многопоточности – к гадалке не ходи. Если еще не встряли, то ~~не мидл~~ еще встрянете. Чтобы избежать таких неприятных ситуаций, нужно учить матчасть по многопоточности на берегу. Для этого пригодится любая специализированная книга по Java Concurrency. Наш выбор остановился на представленной, Java 9 Concurrency Cookbook от Хавьера Гонсалеса как на более свежей. Но можете обратиться и к классике.

Что такое микросервисная архитектура и когда ее применять. Обзорная статья по одной из самых хайповых технологий.
Создаём приложение с чистой архитектурой на Java 11. Отличная статья по реализации архитектуры с нуля на самой свежей версии Java.

https://github.com/code-review-checklists/java-concurrency – чек-лист по многопоточности для ревью кодов. Отличный гайд с перечислением многих нюансов, про которые редко пишут в книгах.
https://github.com/OWASP/CheatSheetSeries/tree/master/cheatsheets – гигантская и всеобъемлющая шпаргалка по безопасности приложений на Java. Мастрид для всех, кто не хочет стать жертвой скрипт-кидди.
https://github.com/akullpp/awesome-java – подборка всякой всячины. Прежде чем приступить к велосипедостроению, просто загляните. Узнаете много нового.
https://www.reddit.com/r/dailyprogrammer – канал на Reddit, в котором регулярно постятся интересные задачи для программистов разных уровней. Публикации призваны помочь попрактиковаться в решении нетривиальных задач и изучить что-то новое.
JHipster – кодогенератор веб-сервисов на стеке Spring Boot + Angular/React. В отличие от остальных кодогенераторов создает экземпляр чистой и хорошей архитектуры. Скачиваем, генерируем, изучаем код для познания best practices.

Программист Java — БудуГуру

Java представляет собой язык программирования и платформу вычислений, которая была впервые выпущена Sun Microsystems в 1995 году. Он используется для разработки корпоративных приложений и видеоигр, веб-приложений с использованием JSP (Java Server Pages), а также родных Android-приложений для смартфонов и планшетов.

Java – один из самых востребованных языков программирования не только в России, но и в мире. В рейтинге, который составил софтверный портал TIOBE, в апреле 2015 года Java занял первое место по популярности Знание Java требуется почти в 14% программистских вакансий — это довольно внушительная доля. А значит Java стоит выучить каждому программисту.

Обязанности

Проектирование и разработка

Главная задача Java-программиста — это создание c помощью одноименного языка разработки приложений и модулей, их архитектуры и логики. При этом программист должен уметь составлять технические задания (ТЗ) и разбираться в специальной терминологии.

Тестирование и внедрение

В задачи Java — программиста также входит сопровождение проекта по созданию приложений или модулей: их тестирование, отладка (в том случае, если обнаружатся ошибки) и, наконец, внедрение — запуск в работу.

Сопровождение

Еще одна обязанность программиста — разработка инструкций по работе с приложениями или модулями, а также оформление необходимой технической документации.

Что нужно знать и уметь

Личные качества

Способность к самообучению;
Системное мышление;
Умение работать в команде;
Аккуратность;
Внимательность;
Самостоятельность;
Инициативность;
Ответственность.

Основные навыки

Знание английского на уровне чтения технической документации.

Отрасли, в которых востребована профессия

Рынок профессии

«Диапазон зарплат» (Москва)

Количество вакансий в динамике

Конкурс на место

Спрос по регионам

Половое соотношение

Возрастное соотношение

Программист Java: требования и необходимые знания

Создает сложные приложения, используя язык Java.

Программист Java – это сложная и интересная профессия, основой которой является разработка продвинутых приложений на одноименном языке программирования. Услуги представителей данной специальности востребованы при создании сайтов электронной коммерции, так как java-приложения способны оперативно и корректно собирать информацию о посетителях интернет-страницы. Спектр обязанностей программистов java также включает в себя улучшение функционала сайта и программное редактирование его дизайна.

Специфика профессии

Работа java-программистом имеет ряд ключевых особенностей, которые являются своеобразным ситом, просеивающим неподходящих кандидатов.

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

Java – это один из самых популярных языков программирования не только в нашей стране, но и во всем мире.

Программист Java: профессиональные навыки

Требования к java-программисту предъявляются достаточно серьезные, ведь истинный профессионал должен обладать минимальным набором навыков:

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

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

Обучение программированию на Java

Ответ на вопрос «как стать java-программистом?» имеет два варианта. Первый – это получение фундаментального высшего образования в области программирования и информационных технологий с последующим самостоятельным изучением языка. Второй – получение соответствующих знаний и навыков на онлайн-курсах и видеоуроках.

Что должен знать программист java – Обучение Java-программист: курс программирования на джава, java developer курс | GeekBrains — образовательный портал | GeekBrains