Совершенствуем навыки через миграцию проектов: способы и примеры

Не секрет, что большой процент ИТ работает над legacy-проектами, — пишет Java-разработчик Николай Литвинчук в своей статье на DOU.UA. — Что это означает для разработчика? Во-первых, это чужой код, у которого скудная документация или её совсем нет. Если вы счастливчик и весь проект полностью описан, то, скорее всего, документация морально устарела ещё несколько лет назад. Во-вторых, необходимо поддерживать этот код без внедрения большого объема новой функциональности. Плюс, в проекте многие вещи воспринимаются как данность. Работает — и хорошо, лучше не соваться без необходимости. И самое важное — на таких проектах старые технологии.

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

Способы получения знаний и навыков

Какие же существуют пути поддержания актуальности своих навыков и знаний?

  • Прочитать мануалы или книгу по конкретной технологии. Дает общее понимание о возможностях, но без практики такие знания плохо откладываются.
  • Походить по собеседованиям. Без комментариев, и так все ясно.
  • Можно пройти курсы по конкретной технологии или даже сдать сертификацию. Дает более углубленное понимание технологии, так как включает в себя практику.
  • Использовать новую технологию в своем pet-project. Наверное, самый лучший вариант, если у вас есть время и собственно pet-project, так как, помимо практики, необходимо решать не синтетические/тестовые задания, а прикладные.

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

Что может дать миграция

Во-первых, вы еще лучше разберетесь с тем монстром, с которым работаете. Так как при миграции могут возникать проблемы, которые никогда не всплывут при повседневной работе. Если, конечно, это не критические баги в production-системе, но там у вас не будет времени, чтобы сильно проникнуться — нужно будет просто подофигеть от причин, быстро пофиксить и перекреститься на всякий случай, даже если не верующий. А то фикс может взорваться в другом месте, и уже придется погружаться ещё глубже.

Во-вторых, вы разберетесь как с новой технологией, так и со старой, потому, что при миграции всегда возникает необходимость переписать несовместимые части.

Что нужно знать до миграции

Во-первых, миграция ради миграции — это не есть хорошо, и надо четко понимать, что она должна решать какую-то проблему и не привносить новые.

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

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

В-четвертых, нужно уметь остановиться и понять, что миграция невозможна. Отсутствие результата — это тоже результат.

В-пятых, это частичная миграция. Категорично против такого, так как плодить зоопарк технологий, которые делают одну и ту же работу параллельно в разных классах/частях системы — это зло. Такое положение часто ведет к проблемам, которые сложно отловить, и необходимостью сопровождать два или более вариантов решения задач. Видел проект, в котором половина доменной области вытягивается при помощи дедовского JDBC, а вторая — Hibernate c кучей eager-связей, что вело к ежедневным падениям приложения с out of memory из-за неверного использования технологии.

Примеры из практики

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

Continuous integration tools. Если проект использует «no name» CI родом из конца 90-х с не user-friendly интерфейсом и проседающим перформансом, то можно перевести его на Jenkins, TeamCity или GitLab CI. Это позволит взглянуть на проект с более высокого ракурса и понять его модульность, найти узкие места и оптимизировать, если возможно. Попутно можно начать хранить артефакты в Nexus, если этого еще не произошло до сих пор. (Прим. ред.: статья написана в 2018 году, какие-то из упоминаемых технологий могли потерять актуальность, но описанные подходы универсальны). Возможно, самый легкий пункт, так как результаты легче всего протестировать. Да и вряд ли найдутся люди, которые будут против такой миграции.

SCM tools. Если у вас есть SVN, то можно мигрировать на Git или Mercurial. Тоже несложный вариант, так как по большей степени может быть выполнен специализированными средствами. Главная сложность — это смена подходов к разработке, а значит может возникнуть сопротивление со стороны команды. Зато есть несомненные плюсы в уменьшении размера репозитория, а также возможность коммитить локально.

Build tools. Если у вас есть Ant, то можно мигрировать приложение на Maven или Gradle. Позволит избавиться от необходимости хранить библиотеки в проекте, плюс разобраться в тонкостях сборки. При такой миграции особых проблем возникнуть не должно, так как на все случаи жизни уже написаны плагины. А если ваш случай уникален — можно написать свой.

Хранение данных. Данные лучше хранить в естественной форме, что упрощает их запись и дальнейшую работу с ними. Не все данные хорошо ложатся на реляционную модель, поэтому можно рассмотреть вариант использования NoSQL баз данных. В одном из проектов была необходимость реализовать анализ логов поисковых запросов с большим количеством опциональных параметров. Писать их дальше в лог файлы было глупо, потому что анализировать это не просто. Поскольку к тому времени популярность набрала MongoDB, то лучшего варианта её применить не нашлось, как для хранения документов с переменным количеством атрибутов и анализа при помощи MapReduce. Сейчас бы такое решение не принял, а выбрал бы ELK stack. Да и мир, как по мне, охладел к NoSQL. Сделал такой вывод, потому что недавно продавал полтора десятка книг по программированию и только «MongoDB в действии» не ушла. Но все же знание NoSQL — это однозначно плюс. Такая миграция — одна из сложнейших с точки зрения сопротивления команды. Потому что внедрение принципиально новых хранилищ данных и их поддержка довольно сложны, а также заставляют мыслить о данных по-новому.

Поиск данных. Как ни крути, но время выполнения поиска — критичный параметр для пользователя. Если вдруг в приложении используется реляционная база данных и никакие индексы не помогают, то логично взглянуть на ElasticSearch, Solr или им подобные решения. Миграция добавит головной боли с индексацией, но с задачей поиска может справиться гораздо лучше RDBMS, плюс есть возможность масштабирования. И хотя в душе отдельные члены команды и заказчик могут быть не в восторге, но против недовольного пользователя не попрешь.

Spring/Spring Boot. Если у вас есть Spring, то можно мигрировать на Spring Boot. Это упростит настройку проекта при помощи замены самописного кода на автоконфигурации, в итоге даже кода станет меньше. Также за годы разработки могут возникнуть сложные решения с контекстами приложения и конфигурации фильтров, с которыми можно будет легче разобраться в процессе миграции. Миграция не особо сложная, но рутинная.

Java version. Каждая новая версия Java имеет ряд нововведений, которые значительно могут упростить жизнь, а по неумению — усложнить. Если брать во внимание позитивный вариант, то использование Streaming api может серьезно облегчить работу с данными, если над ними выполняется много вариантов фильтрации и трансформации при различных состояниях системы. Новый Date/Time api позволит упростить работу с датами, временными зонами и временем. Если ваш проект хотя бы частично покрыт тестами, то такой переход будет не особо сложным.

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


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

P. S. Умышленно пропустил тему frontend-а, потому что в реалиях нашего времени можно мигрировать на новую технологию и в конце миграции обнаружить, что она морально устарела.

[customscript]techrocks_custom_after_post_html[/customscript]

[customscript]techrocks_custom_script[/customscript]

Оставьте комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

Прокрутить вверх