хочу в ibs
  • 19 февраля 2021
От депрессии к смирению: семь стадий развития Enterprise-проекта

Enterprise — это разработка, заточенная под требования конкретного заказчика. Она чаще всего направлена на решение задач бизнеса, а не конечных пользователей.

Отрицание, злость, торг, депрессия, принятие — в какой-то момент мы поняли, что модель Кюблер-Росс весьма точно описывает эмоции команды и этапы в работе над подобными проектами. Рассказываем подробнее на примере реального кейса по созданию аналитической системы в госсекторе.

О проекте

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

Стадия первая: воодушевление

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

Так мы и поступили. В итоге на бэке у нас была шестая Java, Weblogic, Liferay. Бизнес-логика была в базе данных. Данные хранились в Oracle Exadata. SVN мы использовали как систему контроля версии и Oracle BI — как аналитическое решение.

Стадия вторая: злость

Вступает в игру закон Мерфи: все, что может пойти не так, пойдет не так. И с этим нужно будет что-то делать. Выбранное решение может работать нестабильно, в объемной документации зачастую тяжело что-то быстро найти, в интернете оказывается не так много готовых качественных примеров, а команде сложно работать с vendor lock и не всегда актуальными технологиями.

Мы поняли, что выбранные решения написаны далеко не на все случаи жизни. К тому же Oracle Exadata ел немало денег. Oracle BI нас не устраивал полностью — сложный, медленный, не совместимый с современными браузерами. Логика в базе данных — отдельная боль. В целом стек получился своенравным, было сложно искать людей в команду. Начала падать производительность.

Стадия третья: торг

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

Нашим первым решением стал переход на Git — работать с SVN было неудобно. В целях экономии мы хотели отказаться от Oracle Exadata в пользу Oracle RAC. А еще — перенести всю бизнес-логику в Java, отказаться от liferay в пользу классического Spring MVC-приложения, от weblogic — в пользу tomcat, заменить Oracle BI на самописное решение.

Выполнить план на 100% не удалось. Мы не смогли отказаться от liferay, поняли, что написать свою BI-систему в разумный срок нереально, поэтому остались на Oracle BI. Плюс у нас возникли технические трудности с Oracle RAC. И если Oracle Exadata нам многое прощал — например, неоптимальные запросы, то здесь такой подход не сработал.

Стадия четвертая: радость

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

Стадия пятая: депрессия

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

В нашем случае временные решения не только не спасли нас от старых проблем, но и подкинули новых. Наш монолит настолько разросся, что стал долго отлаживаться и собираться три часа. И с каждой новой фичей время увеличивалось. Задач становилось все больше, и мы понимали, что текущие решения им не соответствуют. В это же время вышел закон об импортозамещении ПО в органах власти, что означало неизбежную замену решения Oracle на Postgres.

Стадия шестая: смирение

В этот момент к руководителю проекта приходит полное понимание трех вещей:

  1. Решения от вендоров оптимальны далеко не для всех задач, зачастую слишком унифицированы и переусложнены.
  2. Временные решения не лечат причину, они лишь снимают симптомы. 
  3. Придется тратить ресурсы на более глобальные доработки.

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

Главное, что мы хотели сделать, это перейти на микросервисную архитектуру, чтобы увеличить производительность и решить проблему с масштабируемостью. Также мы решили глобально пересмотреть архитектуру проекта, внедрить гибкие методологии разработки и перейти с Gwt на React\Angular.

В итоге мы успешно выделили микросервисы. Сходу сделать идеальное разделение не получилось, поэтому выбрали итеративный подход. Почти полностью мигрировали на Postgres, отказались от Oracle BI в пользу собственного продукта — «Планеты. Аналитика». И, конечно, внедрили Scrum. Перейти на React\Angular не получилось — мы еще раз проанализировали код и поняли, что переписывать будет слишком дорого, а разработка на Gwt все же идет быстрее.

Стадия седьмая: контроль

Эта стадия обычно следует после глобальных доработок, но по-хорошему должна идти либо до них, либо параллельно. Когда разработчик получает «зеленый свет», часто начинается over engineering — усложняются простые вещи, пишутся супер-универсальные решения на все случаи жизни. Важно вовремя ограничивать этот полет фантазии — детализировать оценки, запрашивать обоснование выбора той или иной технологии и просчитывать альтернативные варианты.

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

Стоит ли игра свеч?

Согласно отчету IDC, рынок Enterprise-разработки в России оценивается почти в 40 миллиардов рублей. Это много. Плюс — это конкурентная среда без выраженных монополистов. Так что да, игра определенно стоит свеч.

И с Enterprise-проектами можно и нужно успешно работать, если помнить о четырех важных вещах.

  1. Эволюция, а не революция: не пытайтесь съесть слона целиком, ешьте его по частям. Составьте план действий и методично претворяйте его в жизнь, придерживайтесь интерактивного подхода.
  2. Не бойтесь open source и современных технологий — так вы решите проблему с рекрутингом, а разработка пойдет быстрее. Но в то же время не стоит слепо гнаться за трендами и модными технологиями с туманным будущим. Соблюдайте баланс.
  3. Будьте гибкими, ищите компромиссы. Порой достаточно простого временного решения, а иногда необходимо настоять на глобальной доработке.
  4. И помните: не бывает идеальных проектов, бывает хорошая команда.

Узнайте больше об Enterprise-разработке и главных трендах на этом рынке — посмотрите запись вебинара IBS «Кровавый Enterprise. Spring Cloud. Unit-тесты».

Команда экспертов IBS
Источник: Сайт IBS
подписаться на рассылку
Материалы экспертов
смотреть все
Ответ
Текст ответа
Хочу у вас работать!
Сопроводительное письмо