Антихрупкость в IT - Александр Васильевич Бындю
Шрифт:
Интервал:
Закладка:
Кажется, единственный шанс окупить всю эту историю с созданием собственного решения – это продажа внутренней low-code платформы на внешнем рынке, потому что сама компания едва ли когда-нибудь окупит эту платформу.
Когда применение low-code оправдано
Мы уже поняли, что сама по себе low-code платформа не принесёт успеха в создании сложной IT-системы. Тем не менее у low-code платформ есть важная характеристика, которую хочется использовать: визуализация алгоритма. То, что скрыто за строчками кода при обычном программировании, нарисовано в виде схемы в low-code платформе. Это даёт возможность аналитикам, владельцам продукта, программистам, проектировщиками общаться на одном языке, глядя на схему процесса.
Работающим подходом является комбинация 1) low-code платформы для визуализации процесса и 2) реализация всех функций этого процесса в виде обычного ПО. Мы применяем для этого BPMN-движки типа Camunda и микросервисную архитектуру. На BPMN описывается процесс, а микросервисы реализуют нужные функции, включая интеграцию, работу с нагрузками, автотесты (рис. 59).
Рис. 59. Разделение визуального описания системы и стандартного подхода с написанием кода
Здесь важно, что BPMN-движок не является самодостаточным, он только организует процесс, оркестрирует. Мы не пишем код внутри Camunda, чтобы потом не упереться в отсутствие рефакторинга и автотестов.
В комбинации low-code + обычное ПО тоже есть сложности. Если подойти к процессу без должного опыта и внимания, то можно создать неподдерживаемое месиво из квадратиков и стрелочек. Тут нужны профессионалы, которые отлично знают нотацию BPMN, хорошие аналитики, готовые разложить процесс на части и учесть все исключительные ситуации. Откуда тогда экономия?
Экономия времени и денег получается за счёт декларативного описания процесса:
1. Его видно, поэтому проще коммуницировать внутри команды и с пользователями.
2. Его могут создать непрограммисты, и они делают это довольно успешно после прохождения обучения по BPMN-движку.
3. Всегда актуальная документация в виде схемы бизнес-процесса. Это как автодокументация, генерируемая по коду, только здесь наоборот – код, генерируемый по документации. Они никак не могут разойтись и всегда соответствуют друг другу.
4. BPMN – довольно популярная нотация, то есть знатоки есть среди разных профессией. При этом эта нотация всеобъемлюща, ею можно покрыть всё необходимое для работы.
Кроме этого, BPMN-движок из коробки реализует часть рутинных операций, которые программистам писать уже не надо, например, таймеры и переходы между этапами.
Есть ли жизнь с low-code?
Пока я делаю вывод, что серьёзную IT-систему не создать без хороших инженеров исключительно на low-code платформе. Low-code оправдано применять для простых интеграций, не критичных для бизнеса.
Между тем у low-code платформ есть выигрышные характеристики. Если грамотно встроить low-code платформу в разработку ПО, то можно нивелировать минусы и сэкономить за счёт плюсов.
Глава 5. Работа с унаследованным кодом
Риски, анализ текущей ситуации и стратегии работы с унаследованными системами
В 9 главе I раздела я описал один из вариантов того, как IT-проект может катиться к провалу из-за слабых технических специалистов и неподготовленных заказчиков. Результатом такого движения будут нарушенные сроки релиза, много плохого кода, негодующие пользователи и грустные инвесторы. После осознания того, что проект идёт к провалу, его отдают команде, которая берёт на себя миссию по спасению, переписыванию или «выпиливанию».
Сейчас я хочу рассмотреть более общий вариант работы со старыми или плохо работающими системами. Хочу дать ответ на вопрос, что делать, если вам досталась в работу legacy system? В этой главе я буду использовать термины legacy system[88] (унаследованная система) и legacy code[89] (унаследованный код).
Вообще, унаследованный – не значит плохой по умолчанию. Бывают унаследованные системы с отличной архитектурой и документацией. Но в этой главе термин унаследованный будет иметь негативную окраску. Я буду говорить о проектах с проблемами в архитектуре, плохим кодом, отсутствием тестов и документации. В этих системах бывает много чего «так исторически сложилось», «это лучше не трогать», использованы устаревшие фреймворки, подходы к разработке, языки программирования и СУБД.
Что такое унаследованная система?
Какие признаки можно выделить для унаследованных систем:
1. Реализованы на старых технологиях и платформах.
2. Используются устаревшие подходы к разработке, дизайну и архитектуре.
3. Нет модульных и интеграционных тестов. Возможно даже, что при текущей реализации системы вообще нельзя написать тесты.
4. В систему трудно вносить изменения, она хрупкая, ломается в неожиданных местах.
5. Плохой нечитаемый код со множеством запахов[90]; иногда непонятно, почему он вообще работает. Как вариант, система с закрытым исходным кодом, но уже без техподдержки со стороны разработчика.
6. Не автоматизированы рутинные операции, что периодически приводит к однотипным ошибкам и повышает bus-фактор[91].
7. Нет документации и описаний по системе, дизайнам и инфраструктуре.
Проект с такими характеристиками точно не будет радовать вас каждый день. Скорее он станет вашей головной болью.
Как системы становятся унаследованными? Можно выделить несколько популярных сценариев:
1. Разработка началась много лет назад. За это время было реализовано много различной функциональности, команды уже несколько раз полностью сменились. Разные части системы написаны в разном стиле. Уже нет людей, которые бы могли рассказать, как система работает в целом. Система проросла корнями во многие части бизнеса, её активно используют, поэтому просто так заменить её нельзя.
2. Система разрабатывалась недолго, но командой с низкой технической компетентностью. Код оброс техническими долгами (раздел ll, глава 5), является очень хрупким. Система почти остановила своё развитие и ждёт героя, который проведёт правильный рефакторинг. Изменения в системе, как и в предыдущем пункте, будут осложняться тем, что её уже используют в работе.
Риски и ответственность
Какие риски могут вас ожидать, если вы решите исправить унаследованную систему или заменить её на новую версию:
1. Унаследованные системы зачастую очень важны для бизнеса. Этими системами уже пользуются, они уже приносят деньги, поэтому ошибки в коде могут очень дорого стоить.
2. Если система уже была запущена, то пользователи научились с ней работать, обходить проблемы, которые она содержит. Например, вы наверняка слышали в магазинах: «Сейчас система зависла, надо подождать немного, потом перезагрузить компьютер, и я проведу оплату ещё раз. Ничего страшного, так бывает». Ваша новая реализация, возможно, будет лучше, но не забывайте про то, что у пользователей уже сложились «ритуалы»,
