Читать книгу - "Антихрупкость в IT - Александр Васильевич Бындю"

у собственной low-code платформы остаются всё те же проблемы с рефакторингом, тестированием, нагрузками и т. д. Эти проблемы остаются, потому что их решение стоит ещё дороже, чем стоимость десятка таких low-code платформ.

Кажется, единственный шанс окупить всю эту историю с созданием собственного решения – это продажа внутренней 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. Если система уже была запущена, то пользователи научились с ней работать, обходить проблемы, которые она содержит. Например, вы наверняка слышали в магазинах: «Сейчас система зависла, надо подождать немного, потом перезагрузить компьютер, и я проведу оплату ещё раз. Ничего страшного, так бывает». Ваша новая реализация, возможно, будет лучше, но не забывайте про то, что у пользователей уже сложились «ритуалы»,