Один день из жизни Java-разработчика. Часть 1

Приветствую, уважаемые коллеги! После публикации «20+ лет спустя», некоторые читатели попросили написать продолжение истории. Про что же еще я мог бы рассказать? Вроде бы, тему о превращении «бородатого эникея» в Java-разработчика я раскрыл полностью. Подвести какие-то итоги можно будет не раньше, чем после года работы. И тогда я решил просто описать, как проходит мой обычный рабочий день. Под катом «Один день из жизни Java-разработчика».

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

Сегодня я первый, и у меня есть полчаса-час тишины до момента, когда подтянутся другие, менее «ранние пташки». Самое время для того, чтобы спланировать сегодняшний день.

Разработку я веду под Linux Mint. Вот нравится мне кнопка «Пуск», скромно и изящно, не то что эти плитки. Десктопный менеджер Cinnamon не перегружен визуальными эффектами, но по степени «вылизанности» немногим уступает MacOS, которая, безусловно, эталон в данном вопросе. Сравнить несложно, вон Mac на соседнем столе, за ним UX-дизайнер работает. К самой ОС у меня тоже почти нет претензий: работает быстро и очень стабильно, перезагружал я ее всего раза три за это время — когда выключал компьютер во время длинных праздников. Собственно, грузится она тоже почти мгновенно, даже заставка появиться не успевает, потому что все компьютеры разработчиков оснащены SSD-дисками.

Первым делом, открываю почтовый клиент Thunderbird, туда приходят письма с информацией об изменениях интересующих меня страниц в wiki (там постановки и спецификации), но главное — оповещения от трекера. Что у нас интересного произошло? О, вернули из тестирования фичу, которую я закончил вчера, похоже, багу нашли. Ну да, так и есть. Надо ее поскорее поправить, может, успею до прихода тестировщика и он, пока еще не влез в какой-нибудь «долгострой», сразу же посмотрит исправления. Вот и первое дело на сегодня имеется. Так, а это уже про мой «долгострой», который я писал весь прошлый спринт. Кажется, на этот раз он успешно выдержал все круги ада этапы тестирования и сегодня, вероятно, его надо будет мержить в основную ветку проекта. Но это попозже, после обеда. Еще сегодня придется поработать девопсом и обновить стенд из ветки, в которой пока ведется разработка, нужно показать новый функционал. «With great power comes great responsibility», выводит предупреждение команда sudo перед тем, как предоставить права root. В моем, несколько вольном, переводе эта фраза звучит как «чем больше ты умеешь, тем больше тебе придется делать». Неудивительно поэтому, что мне, отмеченному «печатью админа», нередко прилетают подобные «пограничные» задачи.

Ну-с, приступим. Вчера я работал над другой фичой, а сейчас мне нужно вернуться на ветку, где бага. «Виндузятники» обычно любят всякие графические оболочки и пользуются Черепахой (TortoiseGit), но мне проще и привычнее через командную строку. Вообще, командная строка в Linux — маленький шедевр, невероятно продуманный и мощный, особенно в сочетании с Midnight Commander. Переключили, теперь надо пересобрать проект. Набираю команду gradle clean ass. Не знаю, была ли эта команда так изначально задумана авторами gradle или случайно получилась, но она просто очищает и пересобирает проект (ass — сокращение от assemble, а вовсе не то, что первым приходит в голову).

На javarush gradle упомянут лишь мельком, как «и другие системы сборки». Да, для сборки учебных проектов никаких преимуществ у gradle перед maven нет. Большинство руководств и how-to в Интернете также используют maven. Появление и растущая популярность gradle, вероятно, вызваны стремительным ростом сложности сборки современных проектов. Проект, в котором участвую я, состоит из нескольких десятков компонентов, где бэкенд написан на Java, фронтенд — на Javascript, а тесты — на Python. Кстати, в наше время сборка Javascript-проекта — отдельный и совсем непростой процесс, который даже название имеет — Web Workflow, и дерево зависимостей там почти такое же развесистое, как в Java. Хорошо, хоть Python-компоненты собирать не нужно, ну, почти не нужно… После сборки и запуска (который тоже нетривиален) необходимо поднять и проинициализировать тестовыми данными целое окружение с реляционной и NoSql-базой данных, очередью сообщений и in-memory кэшем. Потом все это надо опять собрать и запустить уже на сервере CI, а потом деплоить с помощью ansible. При этом разработка, в основном идет под Windows, а «боевые», демо, тестовые и прочие пре-prod сервера, естественно, под Linux.

Я не очень представляю себе, как вообще можно реализовать подобные вещи на maven, а на gradle — вполне. Дело в том, что билд-файл gradle пишется на языке Groovy. Очень кстати забавный язык, говорят, что помесь Java и Ruby, но я не знаю Ruby, зато немного знаю Javascript, и многие конструкции из него тоже работают. Создатели gradle реализовали такой API, что в простых случаях билд-файл выглядит вполне декларативно (и, кстати, на мой взгляд, читается даже легче, чем maven-овский pom.xml), но если нужно что-то более сложное, вся эта декларативность отбрасывается, появляются переменные, функции, классы — словом, все возможности Groovy, который, кстати, может компилироваться и выполняется на той же JVM, что и код на Java.

Сама сборка, как я уже упомянул, кроссплатформенная, но она взаимодействует с окружением, поэтому ее нужно проверять и под Windows тоже. Для этого у меня установлена Windows на виртуальной машине. KVM идет вперед семимильными шагами, и при правильной настройке гостевой системы виртуализация почти незаметна. Да, spice теперь поддерживает два монитора, разрешение экранов подстраивается автоматически, паравиртуализированные драйверы устройств почти не дают потери в производительности. Я порой ловлю себя на мысли, что не ощущаю особой разницы между двумя платформами. Все таки Java — удивительный инструмент, настолько сблизивший два совершенно разных и, порой, даже враждебных друг другу мира — мир проперитарного ПО, крэков, кейгенов и серийников, олицетворением которого является Windows, и мир открытых систем Linux.

Так, проект собрался, запускаем (естественно, тоже через gradle) и смотрим. Ну да, позор на мою седую бороду, не реализовал одно из требований постановки, вот оно, черным по белому в wiki написано. На прошлой работе я регулярно сталкивался с подобной ситуацией и всегда недоумевал, как разработчик мог пропустить целый абзац из спецификации. Да, запросто! Задумался, сосредоточился на другой проблеме — и бага. Только здесь, благодаря нескольким стадиям тестирования, ее отловят, а на прошлом месте — ну, по всякому бывало.

К счастью, тут работы не на долго. Запускаю Idea Ultimate, это кстати один из немногих платных продуктов, используемых в разработке. В принципе, можно обойтись и Community Edition, но к хорошему, например, к интеграции со Spring, быстро привыкаешь. Еще нужна пара терминалов для логов, браузер для фронтенда и wiki, еще один терминал с командной строкой, все движется, мигает… В общем, картинка на экранах двух мониторов начинает приобретать устрашающий вид, типа того, что показывают в малобюджетных фильмах, изображая напряженную работу хакера. Но это еще мелочи, а вот, помню, когда пришлось поднимать и настраивать отказоустойчивый кластер – семь терминальных окон, еще что-то в углу экрана, во всех окнах — какие-то цифры и картинки из ascii-графики… Но я немного отвлекся от работы, а время идет.

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

Тем временем, утро плавно перетекло в день, народ постепенно подтянулся. Скоро stand up meeting, а если по-нашему, то стендап. Вообще-то с него рабочий день должен начинаться, и для большинства «сов» так почти оно и есть. Стендап выступает как граница максимально позднего прихода на работу, опаздывать на него настоятельно не рекомендуется. Ну а для меня — это как перерыв получается. Итак, все встаем.

На стендапе, как водится, разработчики рассказывают, что они делали вчера и что планируют делать сегодня, тестировщики — что тестировали и с каким результатом, ну а начальники, понятно — что планируется делать дальше, какие проблемы возникли и на что надо обратить особое внимание. Команда у нас территориально распределенная, и в полном составе ее можно увидеть только на стендапе (по телевизору, естественно), ну и еще, пожалуй — на общем корпоративе пару раз в год.

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

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

Само обновление автоматизировано и прошло штатно, но после обновления одна из компонент не стартует. Смотрю логи командой less, у нее, кстати, есть очень удобная функция: если нажать Shift-F, она будет постоянно отображать актуальное содержимое файла, для логов самое оно. А это еще что за … странная вещь? Полный экран вопросительных знаков через запятую. Второй экран, третий, десятый… Да сколько же их там? О, кончились, неслабый такой стектрейс получился. Кто-то написал SQL-запрос с оператором IN для отбора нужных записей по списку, и для каждого элемента списка создал параметр. Все работало, пока список не стал содержать больше чем 32767 элементов, после чего терпение SQL-сервера, наконец, лопнуло. Про это надо будет багрепорт написать, но к проблеме с неработающей компонентой это отношения не имеет.

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

Пора пойти пообедать, погода сегодня отличная, кстати. «Ярко-желтый шар, неподвижно висящий в небе и так напугавший горожан, оказался Солнцем». Чуть ли не первый солнечный день в году. Даже с улицы уходить не хочется, но надо — приближается время мержа.

Продолжение следует

6 комментариев

GuitarFactor
Спасибо за интересную историю! Есть вопрос по поводу сборки таких больших проектов, как тот, в котором Вы участвуете. Как всё же осуществляется эта сборка — все компоненты собираются отдельно, а потом каким-то образом соединяются? И неужели maven не способен на такое? Пока для меня это какие-то непонятные вещи — одно дело написать код под бизнес-логику, а другое — собрать, задеплоить и так далее, так что прошу прощения если вопрос нубский)
P.S. gradle clean ass — я проорал)
alex8894
Уважаемый GuitarFactor , разумеется, maven справится со сборкой многокомпонентного проекта, но собрать — это самая простая часть. Куда сложнее создать окружение, в котором система будет запускаться, причем в разных вариантах — на машине разработчика, на сервере CI, на демонстрационном стенде, на препроде, на продакшене. И это окружение должно стабильно воспроизводиться во всем многообразии комбинаций, иначе очень сложно отлаживаться, а автоматические тесты начинают «дребезжать», периодически непредсказуемо падая при фактическом отсутствии ошибок в коде, и толку от них тогда никакого. Автоматический деплой — еще одна, совершенно отдельная тема. Все это, собственно говоря, и называется DevOps. Так вот, для DevOps maven приспособлен плохо, в другие времена он создавался и с другими целями.
NemchinovSergey
Благодарю за статью! Ваши истории читаются очень легко и с интересом.
Сразу захотелось ликбеза про gradle.
ivanglushnev
Очень увлекательно! Спасибо автору.
Dimont
  • Dimont
  • 0
  • Комментарий отредактирован 2017-03-15 22:13:33 пользователем Dimont
Сочно описано! Very impressive! Кстати, эти стэндапы мне всегда действовали на нервы, особенно, когда что-то не получается. Все раппортуют об успехах, а тебе приходится выдумывать отмазки, типа Yesterday it was not my day. I got stuck in [you name it]. Была бы моя воля, я бы их проводил не каждый день, а хотя бы через день.
DefNeo
Книги тебе нужно писать))) Очень хорошо получается))
Только зарегистрированные и авторизованные пользователи могут оставлять комментарии.