Java Junior Developer. Чему я научился за 2 года работы. Какие решал задачи

Всем, привет!

Сегодня я расскажу о том, что узнал за эти 2 года работы в поизции Java Junior Developer, какие задачи пришлось решать.

За это время я сменил 3 компании, ибо, как рассказывал ранее, старался придерживаться принципа: «по году на компанию«. И каждая компания была по своему разная и задачи очень сильно отличались между ними. Поэтому я разделю эту историю на 3 части.

Итак,

Часть 1. Трехзвенка

Моя история началась с одного небольшого стартапа, стек которого представлял из себя классический замес ранних «двухтысячных«:

«Бэк» в виде огромного «Ораклового монолита» из сотен таблиц, справочников, триггеров и, самое интересное, процедур по 50 000 строк кода в каждой. То, что не удавалось решить Оракловыми процедурами, писали во встроенных в Оракл Java-функциях и использовали потом в процедурах. Надо сказать, что до прихода в эту контору, об Оракле я не знал, мягко говоря, ничего.
Все это проксировалось в мир, а точнее в мобильного клиента через Java-звено, которое представляло из себя обычное HTTP-прокси с налетом персистентности на старом «xml-ном Hibernat’е» с кучей «бойлерплейта«.
Второй частью стека была некая Веб-составляющая приема заявок, выполнення на, прости Господи, Ваадине.
Собственно, третья часть стека — это проект мобильного приложения на Андройд Студио.
Ну и последняя, четвертая часть стека — Дельфи-приложение под Windows.

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

В каком виде я пришел на проект?

Я знал, как запустить Eclipse, знал без подробностей базовый Java-core: что есть, циклы, переменные, условия. Без подробностей — это значит, что я даже не ведал ни о каком наследовании, equals, хешкоде, Java memory model, ни о каких конструкторах, гарбедж-коллекторе, коллекциях (даже названия не знал) и прочем. Я не знал, ни про какой Maven, Spring, Hibernate. Читая про Spring, мой мозг отказывался понимать, что происходит, уже на втором предложении вводного текста.

Еще я мог написать простенькое приложение на Swing с формочкой и кнопочкой посередине, выводящей messageBox «Hello!», я так же на тот момент еще не понимал почему в Java нельзя «сбилдить экзешник» и почему так мало компонентов у Swing, в сравнении с Delphi или Visual Basic. То есть, я был уверен, что Ява — это аналог Delphi, язык исключительно для создания оконных приложений под Windows. Я понятия не имел ни про какие сервера приложений, сервлеты, микросервисы и так далее.

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

Еще, я думал, что мобильное приложение должно ходить в удаленную БД напрямую, примерно как ходит серверный бэк через jdbc. И я очень долго не мог понять, почему он так не ходит и в Сети нет примеров, иллюстрирующих это.

Теперь расскажу про круг задач.

Итак, мне предстояло:

переехать с Oracle на PostgreSQL, а все процедуры перенести на бэк Явы. Сразу скажу, учитывая мои познания в Оракле эта задача так и не была выполнена за год даже составом в 2 разработчика. То есть перенесли только данные, таблицы, сиквенсы, триггеры.
предыдущие разработчики оставили нам офис в полностью разрушенном состоянии. Не было ни серверов, ни исходников. Ничего. С нуля подняли сервер, пришлось разобраться с Томкатом, научиться его разворачивать на голом серваке, настраивать. У нас не было никакого nginx, я даже не знал тогда про него. Весь траффик, все адреса — все прописовалось тупо из админки роутера. Разобрался как собрать приложение, научился поднимать «варник» на серверном Томкате.
Восстановил из исходников Андройд-приложение, научился отлаживать его.
Какое-то время, наверное около 2-3 месяцев пришлось слить на Delphi и в частности на FastReport. Это привело меня к тому, что в итоге я поднимал потом 2 резюме — как Дельфи-разработчик и как Джавист.

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

И вот тогда, началось то, что многим наверное показалось «нудным словоблудием» в моем видео про то, как я стал разработчиком в 40 лет:

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

Именно из тестовых заданий, которые мне давали и вопросов, с которыми я встречался на собеседованиях я сам за 3 месяца создал базу, необходимую для смены работы.

Напишу так же, что перед самым уходом с этой конторы, мне пришлось самому проводить интервью, и в итоге, я нанял себе в напарники человека с огромнейшим опытом работы и профильным образованием. С этим человеком мы сразу не сошлись характерами и, это сильно сугубляло ситуацию. Но он был большим спецом в Линуксе и Git’е. А я на тот период не знал об этом ровным счетом ничего. И не смотря на все наши склоки и прения, мне удалось вытянуть с него ту необходимую базу, которая потом не раз «спасла мне жизнь«.

Часть 2. Мир Легаси-кода.

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

В компании работали тысячи человек, десятки тысяч потребителей по всей стране создавали нагрузку на основной сервер компании, который постоянно на графике показывал 99,9% доступной нагрузки, издавая алармы.

IT- отдел занимал несколько зданий. В компании даже разработали свой язык программирования для описания внутренней логики.

Стек плюс-минус был такой же и мне знакомый:

Опять весь бэк висел на Оракле, загруженном под самое небалуйся.
Java занималась обслуживанием сайтов, и обсчетом страховочных коэфициентов. То есть, весь UI был реализован на JSF, если быть более точным на IceFaces. Java была 6-я. Никакого тебе Spring и Hibernate. Здравствуй, jdbc и ejb 3.0.
Главная жопа компании заключалась в двух вещах, а точнее антипаттернах. Начну с первого. Расчеты при заказе страховки велись бэком Оракла, который курировал один отдел, а предварительные расчеты делались бэком на Java, который курировал мой отдел. В итоге, 90% времени разработчиков уходило на то, что разрабы постоянно выясняли, почему страховые премии разошлись. Часто на это тратилось по 2-3 дня. Типичная ситуация, «отдел Оракла» что-то поменял в своих процедурах, а до нас, например, эти правки не дошли. Второй антипаттерн заключался в том, что все расчеты страховки просто лежали огромной простыней бойлерплейта в классах по 20-30 тысяч строк. Сами условия формировались таким образом, что с некой периодичностью выходили определенные приказы от бизнеса: например, «для такой-то марки, такого-то региона, такого-то года выпуска, страховая премия такая-то«. Ни про какие стримы, лямбды и прочее естественно никто там не знал. Как-то попытаться структурировать процесс расчета, применив какой-то паттерн, чтобы убрать бесчисленное кол-во If-ов в голову никому не приходило. В итоге работа представляла из себя просто жуткую рутинную тоску.
Отдельная песня, как в компании был реализован CI: там просто платили 100 000 парню, который поддерживал Glassfish на удаленной Линукс-машине и ручками подкладывал варники, которые ему отправляли через ftp.
Так же, очень весело был реализован вопрос безопасности. Некий «Дельфист-начальник-отдела» решил, что одного Glassfish’а будет не достаточно, поэтому разрабы вынуждены были пилить 2 проекта. Один «war-ник» вешался на Weblogic и дергал через RPC методы другого, висящего на той же машине на Глассфише.

Чем я занимался в этой компании:

Сначала я месяц ждал, когда мне выдадут машину.
Потом я месяц изучал вопрос переезда с Iсefaces на PrimeFaces, а в итоге выяснилось, что это никому не надо.
После этого я выбил себе проект, автоматизирующий процесс сравнения двух рассчетов (см.выше) и, настали времена истинного наслаждения для меня. Мне дали полную свободу и писал проект полностью на стеке Spring + Angular 4, в чем не плохо прокачался.
Но потом у меня его отняли и посадили на почту, где должен был отвечать на письма из серии «опять не сошелся расчет». В этот момент я понял, что «пора валить«.

Часть 3. Банк

Наверное, пока это было самое эпичное и крутое место из всех тех, где я был. Мы делали банк. Крутой банк, не обычный. Таких в России еще не было. Уникальный продукт. по сути, банк будущего. И делали мы его с нуля. То есть, я пришел в самые истоки, когда на проекте был всего 1 разраб.

Начну со стека. По началу стек был весьма грустный:

Java 8 + Vaadin.

Но постепенно мы разогнались и все стало очень интересно и «вкусно»:

Java 11
Kotlin
Elexir
Angular 8
Cloudfoundry
JPA
Wildfly
Infinispan
JackRabbit
Apache Oak
Apache Avro
PostgreSQL
JavaRX
Spring 5, SpringBoot
Apache Artemis
Akka
Spring State Machine
Spring Integration Flow
Spring Events
KeyCloak

Список задач по сути даже не опишешь как-то в двух словах. Это по сути разработка целой платформы с нуля по ТЗ:

проработка архитектуры взаимодействия сервисов
реализация кодовой базы
ревью кода джунов
взаимодействие со сторонними партнерскими сервисами

В чем я конкретно прокачался на проекте:

начну, наверное, с неприятного. До этого ни на одном проекте у меня не было ни code-review, так называемых «мр-ов«, merge request’ов. И, так как я сам набрал себе в команду людей со стажем по 15-25 лет, то первое время мне очень много пришлось работать над собой психологически, ибо мои реквесты не принимали по 5-10 раз. Приходилось постоянно их переделывать.
я никогда до этого не работал с единым код-стайлом и требованиями к нему, чекерами этого самого код-стайла, никогда не обращал внимание на такие вещи как табуляции, пробелы и пропуски переводами строк между блоками кода. Никогда не писал комментарии к методам и JavaDoc. И всему этому пришлось учиться на весьма жестких код-ревью.
очень много было мест из серии «как это написать короче?«. Так до этого, я вообще ничего не знал ни про Stream Api в Java, ни про Лямбды, ни про тернарные операторы, а уж тем более про Функции, Бифункции, Трифункции и прочее, то меня практически весь код заставляли переписывать в функциональном стиле.
научился использовать повсеместно Билдеры и Ломбок, хоть многие его и критикуют.
было конечно же много придирок и к самому коду с точки зрения, что он выполняет. То есть было много откровенно слабых мест. Например, я мог, не подумав, сунуть какое-то обращение к базе в какой-то цикл, хотя его явно можно было вынести.
архитектор, к примеру, не принимал мои предложения по взаимодействию микросервисов, которые были в моей ответственности, пока я не изучил UML и не стал предъявлять их ему в виде sequence-диаграм.
пришлось научиться работать с Постманом и Курлом, в частности с пре-скриптами и environments.
я никогда не работал с тоннелями и ssh. Тоже была отдельная песня, с которой я встретился на проекте. Вообще, на этой позиции много пришлось работать с Линуксом и, я понял, что надо постепенно уходить от Windows как операционной системы.
я никогда не работал с профилированием в Spring, не работал с yml-файлами и, эту тему тоже пришлось лихорадочно постигать.
первый раз в жизни настраивал сам CI для GitLab.
я никогда не читал такие объемы логов. Что-то типа tailf /opt/proj/logs/stdout.log стало для меня очень знакомой командой.
пришлось изучить стек ELK, поработать с Кибаной, научиться готовить json-логи, и конфигурировать логгеры в xml. До этого я не делал этого никогда.
впервые узнал про удаленную отладку.
пожалуй, одной из сложнейших тем, с которой пришлось быстро разобраться была авторизация. Если настройка обычного Spring Security мне еще далась, вклячая работу с «корсами«, то вот OAuth 2.0 пришлось изучать очень долго.
параллельно я сделал на работе свой собственный проект сервиса wishlist’ов на Java 8, SpringBoot и Angular 7. Этот проект много мне дал в плане навыков создания авторизации именно в контексте фуллстека, упаковки Ангуляра Мавеном в Java-проект (это очень долго у меня не получалось), интерцепторов в Ангуляре.
дольно долго разбирался с JavaRx. Крайне сложная и не понятная для меня оказалась штука.
было еще много всяких сложностей, с которыми пришлось ломать себя за время написания нашей платформы. Всего сейчас и не упомнишь. Но основное, я попытался все же собрать для Вас.