Python conf in Kharkiv, Nov 16 with Intel, Elastic engineering leaders. Prices go up 21.10

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

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

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

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

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

  • Прочитать мануалы или книгу по конкретной технологии. Дает общее понимание о возможностях, но без практики такие знания плохо откладываются.
  • Походить по собеседованиям. Без комментариев, и так все ясно.
  • Можно пройти курсы по конкретной технологии или даже сдать сертификацию. Дает более углубленное понимание технологии, так как включает в себя практику.
  • Использовать новую технологию в своем 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-а, потому что в реалиях 2018 года можно мигрировать на новую технологию и в конце миграции обнаружить, что она морально устарела.

P. P. S. Есть еще один вариант поддержания актуальности знаний, который упоминал в статье «Как выжить в круговороте современного IT, или Зачем изучать основы», но не всем он подойдет.

LinkedIn

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

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

Не аргумент, ибо можно разбираться и без внесения рисков для проекта.

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

Еще один классный аргумент: мы за ваши деньги будем изучать технологию которую больше не будем использовать и ту которую __хотим__ использовать (при том что ваша работала нормально).

Для миграции может быть только одна причина — технология с которой мигрируют не решает бизнес-задач. Например:
— Технология содержит критическую уязвимость или баг, которые нельзя/очень дорого исправлять.
— Технология не имеет определенных фич, необходимых для развития системы.
— Пул разработчиков, готовых с ней работать, очень маленький, поэтому специалисты необходимого уровня очень дорогие.

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

це ж «палка о двух концах» — розробники теж можуть сказати — якщо ми не проапдейтим стек технологій з якими ми працюємо, то або платіть нам на N (а може і на М) більше грошей, або ми від вас підемо. От і доводиться мігрувати.

розробники теж можуть сказати — якщо ми не проапдейтим стек технологій з якими ми працюємо, то або платіть нам на N (а може і на М) більше грошей, або ми від вас підемо

Если вопрос поставлен __именно__ так, то надо искать новых разработчиков, а не поднимать ЗП. Потому что есть 2 возможных варианта:
1) Разработчики просто не зрелые как личности и специалисты. Зрелый специалист или сможет обястнить какие именно проблемы есть у текущего стека (тогда не будет разговора про ЗП), или просто уйдет потому что стек ему не подходит.
2) Эти люди все равно уйдут, и технология — это только предлог. В этом случае еще надо поискать проблемы в менеджменте.

"Риба шукає де глибше, а людина — де лучче"©. Розробники працюють не лише за зарплату, а й за нематеріальні блага: лички, рядочки в резюме, кар’єрне зростання, ріспект і уважуху товаришів по цеху. Якщо ти на якійсь п’янці скажеш, що до сих пір працюєш з AngularJS — тебе ж засміють. І ніхто не буде слухати, що фреймворк в принципі вирішує бізнес завдання клієнта. І не факт, що люди підуть, якщо начальство прислуховується, поважає думку розробників, навіщо ж іти, нема жодної впевненості в тому, що на новому місті буде такий же рівень поваги

Якщо ти на якійсь п’янці скажеш, що до сих пір працюєш з AngularJS — тебе ж засміють. І ніхто не буде слухати, що фреймворк в принципі вирішує бізнес завдання клієнта.

Это скорее всего вариант № 1. А «засмеять» еще надо уметь, особенно с учетом того что если работают долго на фреймворке, который не поддерживает модных штук, то скорее всего понимают подходы, которые стоят за фреймворком, лучше и могут рассказать более «низкоуровненые вещи».
Если же просто задачи очень простые, то это будет вариант № 2.

В любом случае денег больше давать не стоит :)

Не аргумент, ибо можно разбираться и без внесения рисков для проекта

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

Еще один классный аргумент: мы за ваши деньги будем изучать технологию которую больше не будем использовать и ту которую __хотим__ использовать (при том что ваша работала нормально).

Уже упоминал в статье, что нужна четкая аргументация и миграция ради миграции или меркантильных соображений — не вариант.

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

Под фразой не решение бизнес-задач можно вообще все что угодно написать, что вы с успехом и сделали:

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

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

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

Если решение принято, то зачем тратить время на разбирания со старой технологией?

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

Если баг не влияет, то он и не критический :)

А вот если сопровождаемость ухудшается или перформанс проседает — это тоже легко может подпадать под бизнес-цели

Что? Вам дали систему в состоянии Х. Вы ничего не делали и у «системы сопровождаемость ухудшается или перформанс проседает». Просто протухло со временем?

Под фразой не решение бизнес-задач можно вообще все что угодно написать, что вы с успехом и сделали:

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

Например, мы мигрировали вермию джавы, потому что в той которую мы использовали, была критическая уязвимость (с ТЛС вроде). Можно было бы заказть фикс у оракла, но это было бы очень дорого, проще было обновить систему.

Если решение принято, то зачем тратить время на разбирания со старой технологией?

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

Что? Вам дали систему в состоянии Х. Вы ничего не делали и у «системы сопровождаемость ухудшается или перформанс проседает». Просто протухло со временем?

Если система писалась условные 5-10 лет назад, то она могла быть рассчитана, к примеру на одновременное использование 100 пользователями, а база данных имела приемлемый ответ при условных 100 000 записей. Но за это время кол-во пользователей увеличилось и данные накопились. И вот вам

Просто протухло со временем?
Например, мы мигрировали вермию джавы, потому что в той которую мы использовали, была критическая уязвимость (с ТЛС вроде). Можно было бы заказть фикс у оракла, но это было бы очень дорого, проще было обновить систему.

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

Это может быть побочным эффектом миграции

Уже «может». В статье была фраза с большей увереностью.

потому что в процессе может возникнуть необходимость что-то переписать/переконфигурировать. А для этого надо хорошо разбираться в новой и старой технологии.

Нет, не нужно хорошо разбираться (в общем случае).

Если система писалась условные 5-10 лет назад, то она могла быть рассчитана, к примеру на одновременное использование 100 пользователями

1) Старость системы и нарузка на которую она расчитана — это несвязаные вещи.
2) Если система не способна выдерживать нагрузку по архитектурным причинам — это не миграция, а редизайн системы.

Я же не против вынужденной миграции, но это не единственная причина для миграции.

1) Вынужденная миграция — это не причина миграции, это вид миграции.
2) Какие адекватные причины для миграции вы видете, кроме той что я указал?

Вообще если версия какой-то библиотеки уже не поддерживается и критические уязвимости/баги там не фиксятся, то лучше бы заранее обновиться.

Нельзя так говорить. Всегда есть трейдофф: иногда нужно обновится, иногда заменить, иногда отказаться от функиональности, иногда забить.

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

А ничего что сейчас обратный тренд — назад к bare metal?

а трохи детальніше, якщо вам неважко? як на мене, так це занадто різке твердження про тренд.

80% компаний в Fortune 500 хостят свою инфраструктуру в приватных облаках и это в основном vmware, более technical savvy делают bare-metal. И это не только потому что у них security и регуляторные concerns.

Вы думаете почему сейчас Kubernetes взрывной рост испытывает? Потому что он позволяет очень эффективно использовать ресурсы облака и делать deployment на bare-metal, что позволяет экономить миллионы долларов на лицензиях и утилизировать железо на максимум.

Держать все в AWS/GCE/Azure это в основном удел стартапов и мудрый СТО большой компании не будет делать vendor lock-in на паблик облако, как минимум потому, что если есть возможность быстрой и безболезненной миграции в другое облако/colocation то это открывает возможности выбить скидку, очень существенную скидку, от вендора.

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

Согласен, что перегнул с 99% процентами. Не учитывал компании, которые могут позволить собственные датацентры. Потому что вариант миграции в таких объемах — это явно вне моей компетенции и таким опытом не владею. Но так как работал на проекте, который анализировал перформанс инфраструктур сознанных при помощи VMware vSphere, то могу сказать, что только поддержание всего этого счастья в идеальном состоянии стоит немалых денег. Поэтому мне даже интересно сравнить затраты таких компаний на содержание своей инфраструктуры vs AWS/GCE/Azure на каких-то партнерских правах.

+ интересно бы посмотреть на источник информации по поводу 80% компаний Fortune 500

Тренды трендами, но нужно отталкиваться от нужд проекта и выбирать оптимальный вариант. Что бы работать с выделенными серверами и настраивать там инфраструктуру нужно тратить много времени и сил, если вы программист. Нужно докинуть базу данных или кэш на отдельный сервак — дополнительные сложности, если нужны лоад балансеры — еще сложнее. В общем тема обширная и достойна отдельной статьи.

Поставьте себя на место СТО, использование AWS или тем более Azure влетает в копеечку. После определенного размера выгоднее часть перенести в приватное облако, главное это избежать over-provisioning, но для этого есть свои тулы.

Что бы работать с выделенными серверами и настраивать там инфраструктуру нужно тратить много времени и сил, если вы программист

Ansible/Terraform и Kubernetes и все становится очень изи.

Да и мир, как по мне, охладел к NoSQL. Сделал такой вывод, потому что недавно продавал полтора десятка книг по программированию и только «MongoDB в действии» не ушла.

Мир охладел к MongoDB. И хвала Аллаху.
Очень плохо, что у многих людей NoSQL ассоциируется в первую очередь с таким бестолковым хранилищем данных.

Зачем мигрировать если на текущем фреймворке нагрузка всего 5% CPU, а на новых по 40%, и на старом можно на свой сервак наскирдовать за 2-3 года, а там придётся всю жизнь хостинг оплачивать?

Затем что текущий фреймворк дырявый например

Дырявый, но последние 4 года он повернулся дыркой в правильном направлении! Рефакторинг хоть и медленно, но идёт!

Раньше начал дальше будешь. Необходимо хорошее визионерство вперед на будущее. Сейчас все может выглядеть весьма хорошо да как бы потом не пришлось в срочном порядке что-то менять. А оправдание будет из серии — ну кто же мог знать.

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

А что если он не апдейтится и к нему security патчи не выходят?

Да ну это все мастдайфильство! Конечно, в старом фреймворке есть проблемы, но за последние 4 года было запилено фич больше, чем за последние 25 лет! Логи отлично почистили и кеш увеличили в два раза! А по скорости запросов в sql Фреймворк поднялся за год на 12 позиций и теперь всего на 115 месте!

Причин может быть несколько
1) Фреймверк катастрофически устарел и работать с этим легаси очередь желающих не стоит и как следствие в какой-то момент понять, что и как работает могут не только лишь все.
2) Задачи которые выставляет бизнес требуют долгих танцов с бубном с текущим фреймверком
3) Технический долг на проекте такой, что даже самые стойкие гребцы подумывают свалить кочегаром на параход.
ИМХО сейчас мало кого волнует сколько там жрет цпу софт пока это не начинает жрать существенную долю прибыли, угрожает работоспособноси проекта или генерует недовольных клиентов.

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

Не принимал участия в таких миграциях
Но есть чувство, что выделенные сервера для 99% решений — это прошлое

Как и писал, миграция ради миграции — это плохо. Но в любом серьезном проекте перед миграцией придется пройти несколько кругов ада, что бы аргументировать необходимость. Реализовать, как минимум тестовую/минимальную миграцию, что бы показать на практике плюсы минусы и понять обьем миграции и усилий. А потом уже пойти на поклон к заказчику. Не вдавался в такие детали, потому что статья не про это, а про то, что миграция может дать сильный буст многим качествам (включая софт скилы) разработчика.

"в воздухе пахнет миграцией"©

Подписаться на комментарии