Совершенствуем навыки через миграцию проектов: способы и примеры
Не секрет, что большой процент украинского ИТ работает над legacy-проектами. Что это означает для разработчика? Во-первых, это чужой код, у которого скудная документация или её совсем нет. Если вы счастливчик и весь проект полностью описан, то, скорее всего, документация морально устарела ещё несколько лет назад. Во-вторых, необходимо поддерживать этот код без внедрения большого объема новой функциональности. Плюс, в проекте многие вещи воспринимаются как данность. Работает — и хорошо, лучше не соваться без необходимости. И самое важное — на таких проектах старые технологии.
В итоге программист, рано или поздно, сталкивается с необходимостью расширения своих знаний, чтобы не устареть самому, вместе с проектом.
Способы получения знаний и навыков
Какие же существуют пути поддержания актуальности своих навыков и знаний?
- Прочитать мануалы или книгу по конкретной технологии. Дает общее понимание о возможностях, но без практики такие знания плохо откладываются.
- Походить по собеседованиям. Без комментариев, и так все ясно.
- Можно пройти курсы по конкретной технологии или даже сдать сертификацию. Дает более углубленное понимание технологии, так как включает в себя практику.
- Использовать новую технологию в своем pet-project. Наверное, самый лучший вариант, если у вас есть время и собственно pet-project, так как, помимо практики, необходимо решать не синтетические/тестовые задания, а прикладные.
Как показывает опыт, есть более сложный, но и более эффективный вариант — попытаться мигрировать часть legacy-приложения на новую версию технологии или даже заменить более новой.
Что может дать миграция
Во-первых, вы еще лучше разберетесь с тем монстром, с которым работаете. Так как при миграции могут возникать проблемы, которые никогда не всплывут при повседневной работе. Если, конечно, это не критические баги в production-системе, но там у вас не будет времени, чтобы сильно проникнуться — нужно будет просто подофигеть от причин, быстро пофиксить и перекреститься на всякий случай, даже если не верующий. А то фикс может взорваться в другом месте, и уже придется погружаться ещё глубже.
Во-вторых, вы разберетесь как с новой технологией, так и со старой, потому, что при миграции всегда возникает необходимость переписать несовместимые части.
Что нужно знать до миграции
Во-первых, миграция ради миграции — это не есть хорошо, и надо четко понимать, что она должна решать какую-то проблему и не привносить новые.
Во-вторых, надо понимать, даст ли на миграцию добро заказчик. А для этого должна быть четкая аргументация с плюсами и минусами перехода. Не встречал заказчиков, которые говорят нет, когда проект просто умоляет об апгрейде, но, думаю, они есть.
В-третьих, это сопротивление команды. В любом случае будут люди, которые против. Если получится их убедить, то все плюсы и минусы у вас уже будут собраны, значит разговор с заказчиком пройдет легче.
В-четвертых, нужно уметь остановиться и понять, что миграция невозможна. Отсутствие результата — это тоже результат.
В-пятых, это частичная миграция. Категорично против такого, так как плодить зоопарк технологий, которые делают одну и ту же работу параллельно в разных классах/частях системы — это зло. Такое положение часто ведет к проблемам, которые сложно отловить, и необходимостью сопровождать два или более вариантов решения задач. Видел проект, в котором половина доменной области вытягивается при помощи дедовского JDBC, а вторая — Hibernate c кучей eager-связей, что вело к ежедневным падениям приложения с out of memory из-за неверного использования технологии.
Примеры из практики
Необходимо обращать внимание на узкие места проекта и нельзя ограничиваться только программным кодом.
Continuous integration tools. Если проект использует «no name» CI родом из конца
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-а, потому что в реалиях 2018 года можно мигрировать на новую технологию и в конце миграции обнаружить, что она морально устарела.
P. P. S. Есть еще один вариант поддержания актуальности знаний, который упоминал в статье «Как выжить в круговороте современного IT, или Зачем изучать основы», но не всем он подойдет.
