Требуется обеспечить работоспособность этого приложения в ОС Linux и поддержку открытой СУБД.
Портировать или переписывать?
При возникновении потребности портирования приложения на другую платформу, в зависимости от условий, наиболее важным из которых является текущий технологический стек, компания всегда встает перед выбором: портировать имеющийся код или переписать с нуля? Даже если текущий технологический стек продукта поддерживается новой платформой, решение в пользу переписать может быть принято по следующим причинам:
Устаревание текущего технологического стека или его неадекватность решаемой задаче в современных реалиях. Например, если продукт (являющийся многопользовательским приложением) написан на С++, можно столкнуться с множеством проблем на всех этапах его жизненного цикла. Первая – недостаток разработчиков на рынке. Современные разработчики С++ хотят работать в тех сферах, где применение их инструмента оправданно: это высокая нагрузка и системная разработка. Найти адекватного разработчика, который возьмется писать сложную бизнес-логику на C++, затруднительно. Следующая проблема – высокая стоимость добавления функций: то, что можно сделать на современном фреймворке за два дня, на устаревшем стеке можно делать две недели или два месяца, а потом еще столько же тестировать. Высокая стоимость поддержки и низкая скорость устранения дефектов – еще одно последствие, которое влечет за собой использование устаревших технологий.
Проблемы с высокоуровневой архитектурой и большой технический долг. Масштабные изменения, сопутствующие портированию, могут быть удачным поводом для пересмотра архитектуры, а в случае необходимости глобальных изменений пересмотр стека основных технологий может значительно ускорить выполнение задачи и заложить хорошую базу для развития продукта.
Вне зависимости от принятого решения относительно изменения стека при любых масштабных нефункциональных изменениях продукта подход к выполнению задачи будет примерно одинаков.
Проектирование
На этапе проектирования необходимо:
1) проработать архитектуру развертывания и ответить на вопросы:
2) экспериментально подтвердить все основные архитектурные решения, направленные на поддержку нового окружения. Если меняется способ кластеризации, стоит проверить, используется ли какое-то окружение, доступное на обеих платформах, и уточнить сценарии работы с ним в новой инфраструктуре. Результатом должна стать уверенность в реализуемости выбранного технического решения.
Разработка
Сама разработка при портировании будет разделена на два больших этапа:
Первый этап ввиду новизны для команды разработки и наличия рисков (особенно если был пропущен или недостаточно тщательно выполнен второй этап проектирования) плохо прогнозируем по срокам и должен выполняться относительно небольшим количеством ведущих разработчиков. Это позволит заложить правильную основу и избежать множества "грабель", на которые команда сможет наступить в будущем. Если при портировании не происходит полная замена платформы, то перенос функций пройдет проще, поскольку как минимум часть приложения сохранит свой первоначальный вид и поведение, на которое можно опираться при тестировании. Если же производится замена платформы, то неплохим подспорьем может стать документация, описывающая пользовательские сценарии. Не имея ее, крайне сложно сохранить все функции и особенности поведения, необходимые пользователям.
Положительную роль на этапе разработки может сыграть применение гибкой методологии (в первую очередь Scrum), что при наличии документации с описанием пользовательских историй и сценариев позволит достаточно точно прогнозировать трудозатраты и сроки, а также масштабировать команду разработки на этапе переноса функций.
Критерии выбора технологического стека
В случае если принято решение о полной замене технологического стека, выбор, доступный в современном мире разработки, может ввести в заблуждение даже опытных проектировщиков, поработавших какое-то время в определенной технологической нише. Помимо функциональных требований, стабильности и надежности выбираемого инструмента, стоит учитывать следующие моменты:
Первое: внешние зависимости необходимо свести к минимуму. Под внешними я понимаю любые сервисы, которые разворачиваются и сопровождаются отдельно от ПО. Например, если нет веских оснований использовать ApacheKafka и есть возможность реализовать необходимые кейсы, решаемые им, на уровне своего ПО или с помощью встраиваемых зависимостей, стоит отдать предпочтение встроенной реализации.
Конечно, есть зависимости, реализация которых неподъемна и неадекватна на уровне прикладной системы, например СУБД или Web-сервер. Для таких случаев стоит воздержаться от использования новых, не принятых в индустрии решений. К примеру, NoSQL СУБД, возможно, даже больше подходит продукту по архитектуре, нежели традиционное решение, но она явно не будет тепло принята клиентами – крупными компаниями. Прежде чем ее применять, стоит еще раз взвесить все за и против.
Web-технологии – отдельный предмет для разговора. Тренды в них меняются настолько часто, что продукт с использованием нового крутого SPA-фреймворка еще не выпущен, а уже устарел, и фронтэндеры с рынка не хотят с ним работать. Здесь важно соблюсти разумный баланс между новизной и качеством и, возможно, отказаться от применения каких-то нововведений в принципе в пользу более простых и доступных фуллстек-разработчикам технологий. Все вышесказанное – квинтэссенция опыта, полученного в реальных условиях разработки коммерческого продукта. Надеюсь, что этот опыт поможет специалистам в принятии важных решений, убережет от ошибок или сподвигнет на реализацию казавшейся неподъемной задачи.
Александр Махновский, руководитель отдела разработки Аванпост
Хотя в 2018 году многие крупные ИТ-проекты, включая проекты перехода на импортонезависимое ПО, были отложены, у коммерческих и государственных предприятий крепнет понимание необходимости масштабных изменений организационного уровня на основе цифровизации.
Портал «Понедельник» попросил экспертов оглянуться на прошедший год. Какие технологии обеспечивали лидерство? На какие стоит делать ставку в дальнейшем? А главное, что насчет искусственного интеллекта и роботов в 2019 году, они уже появятся повсеместно или все еще нет?