7140
правок
Изменения
Новая страница: «Весенняя конференция [https://analystdays.ru/ru/program/105281 '''AnalystDays'''] порадовала меня содержанием докл…»
Весенняя конференция [https://analystdays.ru/ru/program/105281 '''AnalystDays'''] порадовала меня содержанием докладов, которое, по моим впечатлениям, улучшилось с прошлой конференции. А еще был замечательный afterparty с хорошей музыкальной группой, которой удалось запустить танцпол - это редкость на IT-конференциях. И при этом музыка не исключала содержательного общения, что тоже важно.
Я публиковал впечатления с докладов сразу в ходе конференции, и сейчас собираю из них отчет. К сожалению, у меня получилось быть только первый день, потому что второй пересекся с конференцией Школы системного менеджмента ([[ |мой репортаж]]), поэтому в репортаже наверняка нет многих ценных докладов.
= Мой доклад Требования или модели - как писать постановки =
Сам я выступал с докладом [[Требования или модели - как писать постановки (AnalystDays-2023)|'''Требования или модели - как писать постановки''']]. В докладе был систематизированный обзор различных способов создания постановок. Представлять спектр возможностей - очень важно, потмоу что проекты - разные и стоит выбирать способ исходя из проекта, потому что универсального способа точно нет. Доклад поучился очень содержательным и удачным и занял третье место среди докладов конференции, что было для меня приятным сюрпризом.
Отмечу, что в 2017 я делал доклад о сборке метода для написания постановок [[Как выбрать для проекта практики проектирования и работы с требованиями (Максим Цепков на AnalystDays-2017)|'''Как выбрать для проекта практики проектирования и работы с требованиями''']], но там содержание существенно отличалось: фокус был на том, на какие вопросы следует ответить и какие аспекты этого процесса рассмотреть, в то время как в этом докладе фокус - на различии разных методов и их назначение.
А еще я планирую продолжить эту тему на [http://lafest.ru '''ЛАФ'''] 9-11.06, фокусируясь на Domain Driven Design в современных условиях. Об этом у меня тоже был доклад 10 лет назад, с тех пор видение существенно развивалось: появилось понимание отличий DDD от построения объектных моделей (OOAD), осознание различий между проектированием автоматизации «с чистого листа» и заменой существующей основной системы, представление о применении DDD в современной микросервисной архитектуре и многое другое.
= Юрий Куприянов, ChatGPT в работе аналитика =
Очень подробный рассказ про использование ChatGPT в роли помощника аналитика, с примерами из разных предметных областей. Что он может сделать? Помочь разобраться в предметной области, сделать план интервью, самому провести интерфейс с тобой, построить по тексту модель объектов и связей, построить диаграмму бизнес-процессов, диаграмму классов и диаграмму последовательности по текстовым описаниям, описать user story и use case, сделать SRS на приложение, предложить API интеграции, сделать описание по коду, написать SQL-запрос. Графики он строит через вывод результатов в формате graphviz или plantuml или bpmn, дальше их копируешь. Ответы - уточняешь и просишь дополнить. В докладе все было достаточно подробно, с техникой развернутых вопросов, примерами детализации ответов, и это можно увидеть в презентации, которая будет очень скоро. Все это не значит, что ChatGPT заменит аналитика, но он его явно усилит. И Юра сказал, что в последнее время все больше использует эти возможности в реальной работе. Что круто.
= Леонид Юденков. Рациональное "нет". Как отказать бизнесу и остаться друзьями =
Рассказ о типовых конфликтах при взаимоотношении с бизнесом.
Модель-1. Продуктовая команда, она выдвигает гипотезы и апробирует на рынке. CustDev, метрики и так далее. PO в команде, контроль сроков, ресурсов, бюжета и качества - внутри.
Модель-2. Команда продукта или проекта, вместо рынка - бизнес. Инхауз, заказная разработка и так далее. В команде тогда Proxy PO. Команда разработки контролирует ресурсы и качество, а у бизнеса - бюджет и желаемые сроки (новая версия - до годовой отчетности или новогодних распродаж).
В Модели-2 вместо гипотез появляются Требования. И требования - довольно жестко, они у террористов или детей. Аналитик - между бизнесом и командой. И что делать, если они не конструктивны, вредны для архитектуры и так далее.
Ситуации: новые неучтенные требования, нарушение договоренностей, вредные требования, решение вместо потребности, влияние на сроки. Хочется сказать НЕТ, но правильно - сдержаться, действовать контринстинктивно. И дальше был разбор по каждой ситуации.
Новые требования. Возникают по разным причинам, могут оказаться каплей в море, а могут серьезно повлиять на объем. Рушат планы. Первым делом надо классифицировать, оценить и приоритизировать.
Нарушение договоренностей. Могут быть вызваны сменой курса или подковерной игрой. Всегда представляют интересы того, кто инициирует изменение. Помимо влияния на планы, концепцию и архитектуру, могут подрывать доверие между бизнесом и разработкой. Первым делом надо разобраться, почему это произошло, это смена курса или что-то еще?
Решение вместо потребности. Нужно размотать задачу до исходной проблемы (pain point) и ее носителя. Очень аккуратно и бережно - кто-то сделал работу и ее нельзя обесценить, даже если у него не получилось.
Вредные требования, нарушающие архитектуру, подходы к дизайну и т.д. Главное - понять, почему выдвигаются требования именно в таком виде. Бизнес пытается решить проблемы так, как видит? и у него есть основания. Например, добавить blockchain - потому что министр сказал "в любой нормальной системе должен быть blockchain" - и они развернули мини-сетку, куда скидывали логи при смене состояния, дешевая штука, которую потом выпилили.
Попытка сократить сроки. Надо понимать, что если бизнес давит на вас, значит что-то начало давить на него. Надо докопаться до этой причины и решать с учетом этого.
Негативные паттерны. Могут быть оправданы, но точечно.
* Радикальный отказ. Этим мы сжигаем мостик, не слушаем потребности. Это может решить здесь и сейчас, но в долгую - в минус.
* Конфронтация. Можно, но очень осторожно. И не факт, что поможет.
* Соглашательство или пассивное согласие. Деморализация и аналитика и команды.
Позитивные паттерны
* Демонстрация лучших решений, альтернатив. И критерии сравнения подберите так, чтобы его сами выбрали.
* Рассказать о самых плохих последствиях предлагаемого решения. Сгущать тучи, но не сочинять проблемы.
* Приводить примеры из опыта - когда принятие негативного решения или не принятия влекло негатив.
* Говорить на языке цифр
* Привлекайте экспертов. Надо согласовать позиции и даже разыграть спектакль с хорошим и плохим полицейским.
* Устранение корневой проблемы или workaround. Решайте что боли. Придумайте, как минимальными усилиями бизнес может показать правильный отчет о решении задачи.
Матрица: Эффективность в моменте против долговременного партнерства.
Переговорная теория и концепция win-win. Есть теория для разовых переговоров, управленческих поединков, когда извлекаешь максимум профита в моменте. Это стратегия win-lose, и вдолгую она не оправдывается.
Что делать, если партнер не хочет сотрудничать? Тогда используйте переговоры win-lose, отказывайте четко и аргументировано, вызывайте контролируемый конфликт, привлекайте дополнительный вес - эскалация. Или дайте бизнесу просто ошибиться.
Business Relationship Maturity Model - 5 уровней, от работы по запросу ad hoc до стратегического партнерства.
Итого: нет говорить можно, иногда нужно, но рационально. пытайтесь понять, что болит у заказчика. Оставайтесь экспертами. Стройте отношения в долгую.
= Александра Дахина из SM Lab. Как мы учим бизнес готовить вкусные дашборды =
Они используют Tableau, в котором очень много возможностей, но он сложен, хотя порог входа для простых дашбордов - низкий. Дашбордов надо много, и большинство из них - простые. Поэтому решение - ревью готовых дашбордов, который готовят начинающие разработчики или даже бизнес, которое позволяет быстро обучать людей готовить вкусные дашборды.
Дашборд - красивые интерактивные визуализации с быстрыми фильтрами и drill-down. Вкусные: функциональные, производительные, красивые.
* Функциональные - облегчают принятие решений, отвечают на нужные вопросы - не надо сопоставлять дофига данных вручную, не заставляют страдать пользователей - интуитивно-понятные
* Производительные - не ждешь ответа, заваривая чай, случайные нажатия не приводят к непонятным переходам.
* Красивые: облегчают принятие решений, тип визуализации отвечают задачам, не диаграммы с 20 сегментами, в которых не разберешься, единый стиль, хорошие цвета и текст.
Два вида ревью: потоковое для обучения перед публикацией, а также при внедрении новых практик и техническое - когда проблемы с производительности или сложная доработка существующего или оптимизация визуализации для восприятия. Нужен ревьюер, разбирающийся в инструменте и понимающий контекст бизнеса. Ревьюер может помогать 3+ разработчиком. Разработчики отчетов с базовым пониманием инструмента. Разработчики должны уметь планировать с учетом времени на ревью. И должен быть процесс с ограничением времени с обоих сторон. И понятный список критериев ревью, возможных проблем - не вкусовщина.
На каждое ревью - задача в jira, в которой описание и ссылка на задачу. Первый шаг ревьюера - до 3 дней, обычно один, результат - список замечаний в confluence. Дальше доработка, срок - 2 недели. Если не успели - задача уходит в песочницу. После доработки - новое ревью. Чек-лист проверки. 7 разделов: источники, вычисления, фильтры, визуализация, дашборд, общее оформление, правила публикации. 66 критериев. Есть обязательные требования (фильтр по дате обновляется при открытии), технические критерии, рекомендации, style guide.
Что обеспечено.
* Скорость без потери качества. Один опытный делал бы больше, а новички - хуже.
* Быстрый рост разработчиков. Для этого нужны развернутые комментарии по результатам ревью - чтобы понимали причины.
* Приучение пользователей к вкусным дашбордам, и формируют требования к следующим с учетом этого.
= Ильдар Гиматдинов. Архитектор системы vs Архитектор решения =
Очень интересное сопоставление двух архитекторов. Software Architect отвечает за архитектуру приложений вместе технологическим уровнем, а Solution Architect обеспечивает согласованное понимание на всех уровнях, вертикальный колодец от стратегии и бизнес-архитектуры до архитектуры приложений и технологическая. В докладе было два разных взгляда на интернет-банкинг как модельный пример. Фокус первого - на стоимость владения, на выверенную архитектуру и правильные, выверенные решения. А второго - на поддержку бизнеса, на гибкость системы. Оба используют диаграммы, но разные, потому что разные viewpoint. Хотя основой для обоих может быть Archimate. Для Архитектора систем хорошо подходит c4model. Хорошая диаграмма - вложенные компоненты и потоки данных между ними. Архитектор решений -связь уровней: бизнес и его поддержка на уровне приложений. Архитектор решений борется за понимание, однако упрощение не должно скрывать сложность, которая вскроется на этапе реализации. Бизнес должен понимать сложность решения.
= Александр Теплицкий из Райффайзена. От монолита к микросервисам =
Ценность доклада в том, что он не только о технике, большая часть посвящена организации: определению целей, получение информации об устройстве монолита и организации постепенного перехода. На примере разделения интернет-банка для того, чтобы гибко масштабировать нагруженные узлы, отвечающие за частые операции и развивать отдельные продукты без деплоя огромного приложения. А еще - сэкономить на лицензиях за счет переписывания.
Надо принять решение по принципам.
* Способ выделения: по поддоменам (объектам данных) или по функциям.
* Один сервис - одна БД или несколько с одной БД для согласованности данных.
* Сага - последовательность локальных транзакций в ряде сервисов для согласованности операций
* API-композиция - запрос данных из разных сервисов и объединение в памяти
* Доменные события - публикуем на каждое изменение
* События как источник - храним сущности как последовательность событий, собираем цельный документ по событиям на чтении - потому что у них изменений много больше, чем чтений.
Не пишем сразу все микросервисы с однократным переходом, а переводим постепенно. Фаулер: если вы переписываете все и сразу, то у вас получится только сломать все и сразу.
Надо разделять deploy и release. После деплоя - проверяем в продакшене, но пользователей не запускаем. Можно откатить. И только после проверки - релиз, с плавным переводом пользователей на новый сервис. Постепенный переход позволяет увидеть проблемы. Например, больше сервисов - больше сетевых взаимодействий - могут появиться проблемы, их увидим. А еще можно решить, что целей достигли до того, как полностью выключили монолит и оставить его.
Шаги изменения, на примере выделения отправки документа и файла от из интернет-банка в банковские системы исполнения.
* Собрали отправку файла в отдельный компонент file-sender внутри монолита
* Поставили перед отправкой файла отдельный интерфейс
* Сделали собственный отдельный сервис на основе выделенной отправки файла
* Поставили в интерфейсе переключатель: используем встроенный компонент или вызываем внешний сервис
* Переключаем, проверяем
* Убираем отправку файла из монолита.
Работа с данными на переходе. Для обкатки - можно напрямую обратиться к БД монолита. Потом - определяем данные, их передаем в API, делаем отдельное хранение.
= Татьяна Яковлева. Инструменты для визуализации данных: от простого к сложному =
Хорошая личная история развития аналитика: от анализа данных в Excel к созданию там дашборд, подключенного к базе данных и далее - к дашбордам на python dash. Вывод: все доступно, дорогу осилит идущий, на этой дороге сложностей нет, а где есть, например, с CI/CD - разработчики помогут.
{{wl-publish: 2023-05-16 11:38:00 +0300 | MaksTsepkov }}
Я публиковал впечатления с докладов сразу в ходе конференции, и сейчас собираю из них отчет. К сожалению, у меня получилось быть только первый день, потому что второй пересекся с конференцией Школы системного менеджмента ([[ |мой репортаж]]), поэтому в репортаже наверняка нет многих ценных докладов.
= Мой доклад Требования или модели - как писать постановки =
Сам я выступал с докладом [[Требования или модели - как писать постановки (AnalystDays-2023)|'''Требования или модели - как писать постановки''']]. В докладе был систематизированный обзор различных способов создания постановок. Представлять спектр возможностей - очень важно, потмоу что проекты - разные и стоит выбирать способ исходя из проекта, потому что универсального способа точно нет. Доклад поучился очень содержательным и удачным и занял третье место среди докладов конференции, что было для меня приятным сюрпризом.
Отмечу, что в 2017 я делал доклад о сборке метода для написания постановок [[Как выбрать для проекта практики проектирования и работы с требованиями (Максим Цепков на AnalystDays-2017)|'''Как выбрать для проекта практики проектирования и работы с требованиями''']], но там содержание существенно отличалось: фокус был на том, на какие вопросы следует ответить и какие аспекты этого процесса рассмотреть, в то время как в этом докладе фокус - на различии разных методов и их назначение.
А еще я планирую продолжить эту тему на [http://lafest.ru '''ЛАФ'''] 9-11.06, фокусируясь на Domain Driven Design в современных условиях. Об этом у меня тоже был доклад 10 лет назад, с тех пор видение существенно развивалось: появилось понимание отличий DDD от построения объектных моделей (OOAD), осознание различий между проектированием автоматизации «с чистого листа» и заменой существующей основной системы, представление о применении DDD в современной микросервисной архитектуре и многое другое.
= Юрий Куприянов, ChatGPT в работе аналитика =
Очень подробный рассказ про использование ChatGPT в роли помощника аналитика, с примерами из разных предметных областей. Что он может сделать? Помочь разобраться в предметной области, сделать план интервью, самому провести интерфейс с тобой, построить по тексту модель объектов и связей, построить диаграмму бизнес-процессов, диаграмму классов и диаграмму последовательности по текстовым описаниям, описать user story и use case, сделать SRS на приложение, предложить API интеграции, сделать описание по коду, написать SQL-запрос. Графики он строит через вывод результатов в формате graphviz или plantuml или bpmn, дальше их копируешь. Ответы - уточняешь и просишь дополнить. В докладе все было достаточно подробно, с техникой развернутых вопросов, примерами детализации ответов, и это можно увидеть в презентации, которая будет очень скоро. Все это не значит, что ChatGPT заменит аналитика, но он его явно усилит. И Юра сказал, что в последнее время все больше использует эти возможности в реальной работе. Что круто.
= Леонид Юденков. Рациональное "нет". Как отказать бизнесу и остаться друзьями =
Рассказ о типовых конфликтах при взаимоотношении с бизнесом.
Модель-1. Продуктовая команда, она выдвигает гипотезы и апробирует на рынке. CustDev, метрики и так далее. PO в команде, контроль сроков, ресурсов, бюжета и качества - внутри.
Модель-2. Команда продукта или проекта, вместо рынка - бизнес. Инхауз, заказная разработка и так далее. В команде тогда Proxy PO. Команда разработки контролирует ресурсы и качество, а у бизнеса - бюджет и желаемые сроки (новая версия - до годовой отчетности или новогодних распродаж).
В Модели-2 вместо гипотез появляются Требования. И требования - довольно жестко, они у террористов или детей. Аналитик - между бизнесом и командой. И что делать, если они не конструктивны, вредны для архитектуры и так далее.
Ситуации: новые неучтенные требования, нарушение договоренностей, вредные требования, решение вместо потребности, влияние на сроки. Хочется сказать НЕТ, но правильно - сдержаться, действовать контринстинктивно. И дальше был разбор по каждой ситуации.
Новые требования. Возникают по разным причинам, могут оказаться каплей в море, а могут серьезно повлиять на объем. Рушат планы. Первым делом надо классифицировать, оценить и приоритизировать.
Нарушение договоренностей. Могут быть вызваны сменой курса или подковерной игрой. Всегда представляют интересы того, кто инициирует изменение. Помимо влияния на планы, концепцию и архитектуру, могут подрывать доверие между бизнесом и разработкой. Первым делом надо разобраться, почему это произошло, это смена курса или что-то еще?
Решение вместо потребности. Нужно размотать задачу до исходной проблемы (pain point) и ее носителя. Очень аккуратно и бережно - кто-то сделал работу и ее нельзя обесценить, даже если у него не получилось.
Вредные требования, нарушающие архитектуру, подходы к дизайну и т.д. Главное - понять, почему выдвигаются требования именно в таком виде. Бизнес пытается решить проблемы так, как видит? и у него есть основания. Например, добавить blockchain - потому что министр сказал "в любой нормальной системе должен быть blockchain" - и они развернули мини-сетку, куда скидывали логи при смене состояния, дешевая штука, которую потом выпилили.
Попытка сократить сроки. Надо понимать, что если бизнес давит на вас, значит что-то начало давить на него. Надо докопаться до этой причины и решать с учетом этого.
Негативные паттерны. Могут быть оправданы, но точечно.
* Радикальный отказ. Этим мы сжигаем мостик, не слушаем потребности. Это может решить здесь и сейчас, но в долгую - в минус.
* Конфронтация. Можно, но очень осторожно. И не факт, что поможет.
* Соглашательство или пассивное согласие. Деморализация и аналитика и команды.
Позитивные паттерны
* Демонстрация лучших решений, альтернатив. И критерии сравнения подберите так, чтобы его сами выбрали.
* Рассказать о самых плохих последствиях предлагаемого решения. Сгущать тучи, но не сочинять проблемы.
* Приводить примеры из опыта - когда принятие негативного решения или не принятия влекло негатив.
* Говорить на языке цифр
* Привлекайте экспертов. Надо согласовать позиции и даже разыграть спектакль с хорошим и плохим полицейским.
* Устранение корневой проблемы или workaround. Решайте что боли. Придумайте, как минимальными усилиями бизнес может показать правильный отчет о решении задачи.
Матрица: Эффективность в моменте против долговременного партнерства.
Переговорная теория и концепция win-win. Есть теория для разовых переговоров, управленческих поединков, когда извлекаешь максимум профита в моменте. Это стратегия win-lose, и вдолгую она не оправдывается.
Что делать, если партнер не хочет сотрудничать? Тогда используйте переговоры win-lose, отказывайте четко и аргументировано, вызывайте контролируемый конфликт, привлекайте дополнительный вес - эскалация. Или дайте бизнесу просто ошибиться.
Business Relationship Maturity Model - 5 уровней, от работы по запросу ad hoc до стратегического партнерства.
Итого: нет говорить можно, иногда нужно, но рационально. пытайтесь понять, что болит у заказчика. Оставайтесь экспертами. Стройте отношения в долгую.
= Александра Дахина из SM Lab. Как мы учим бизнес готовить вкусные дашборды =
Они используют Tableau, в котором очень много возможностей, но он сложен, хотя порог входа для простых дашбордов - низкий. Дашбордов надо много, и большинство из них - простые. Поэтому решение - ревью готовых дашбордов, который готовят начинающие разработчики или даже бизнес, которое позволяет быстро обучать людей готовить вкусные дашборды.
Дашборд - красивые интерактивные визуализации с быстрыми фильтрами и drill-down. Вкусные: функциональные, производительные, красивые.
* Функциональные - облегчают принятие решений, отвечают на нужные вопросы - не надо сопоставлять дофига данных вручную, не заставляют страдать пользователей - интуитивно-понятные
* Производительные - не ждешь ответа, заваривая чай, случайные нажатия не приводят к непонятным переходам.
* Красивые: облегчают принятие решений, тип визуализации отвечают задачам, не диаграммы с 20 сегментами, в которых не разберешься, единый стиль, хорошие цвета и текст.
Два вида ревью: потоковое для обучения перед публикацией, а также при внедрении новых практик и техническое - когда проблемы с производительности или сложная доработка существующего или оптимизация визуализации для восприятия. Нужен ревьюер, разбирающийся в инструменте и понимающий контекст бизнеса. Ревьюер может помогать 3+ разработчиком. Разработчики отчетов с базовым пониманием инструмента. Разработчики должны уметь планировать с учетом времени на ревью. И должен быть процесс с ограничением времени с обоих сторон. И понятный список критериев ревью, возможных проблем - не вкусовщина.
На каждое ревью - задача в jira, в которой описание и ссылка на задачу. Первый шаг ревьюера - до 3 дней, обычно один, результат - список замечаний в confluence. Дальше доработка, срок - 2 недели. Если не успели - задача уходит в песочницу. После доработки - новое ревью. Чек-лист проверки. 7 разделов: источники, вычисления, фильтры, визуализация, дашборд, общее оформление, правила публикации. 66 критериев. Есть обязательные требования (фильтр по дате обновляется при открытии), технические критерии, рекомендации, style guide.
Что обеспечено.
* Скорость без потери качества. Один опытный делал бы больше, а новички - хуже.
* Быстрый рост разработчиков. Для этого нужны развернутые комментарии по результатам ревью - чтобы понимали причины.
* Приучение пользователей к вкусным дашбордам, и формируют требования к следующим с учетом этого.
= Ильдар Гиматдинов. Архитектор системы vs Архитектор решения =
Очень интересное сопоставление двух архитекторов. Software Architect отвечает за архитектуру приложений вместе технологическим уровнем, а Solution Architect обеспечивает согласованное понимание на всех уровнях, вертикальный колодец от стратегии и бизнес-архитектуры до архитектуры приложений и технологическая. В докладе было два разных взгляда на интернет-банкинг как модельный пример. Фокус первого - на стоимость владения, на выверенную архитектуру и правильные, выверенные решения. А второго - на поддержку бизнеса, на гибкость системы. Оба используют диаграммы, но разные, потому что разные viewpoint. Хотя основой для обоих может быть Archimate. Для Архитектора систем хорошо подходит c4model. Хорошая диаграмма - вложенные компоненты и потоки данных между ними. Архитектор решений -связь уровней: бизнес и его поддержка на уровне приложений. Архитектор решений борется за понимание, однако упрощение не должно скрывать сложность, которая вскроется на этапе реализации. Бизнес должен понимать сложность решения.
= Александр Теплицкий из Райффайзена. От монолита к микросервисам =
Ценность доклада в том, что он не только о технике, большая часть посвящена организации: определению целей, получение информации об устройстве монолита и организации постепенного перехода. На примере разделения интернет-банка для того, чтобы гибко масштабировать нагруженные узлы, отвечающие за частые операции и развивать отдельные продукты без деплоя огромного приложения. А еще - сэкономить на лицензиях за счет переписывания.
Надо принять решение по принципам.
* Способ выделения: по поддоменам (объектам данных) или по функциям.
* Один сервис - одна БД или несколько с одной БД для согласованности данных.
* Сага - последовательность локальных транзакций в ряде сервисов для согласованности операций
* API-композиция - запрос данных из разных сервисов и объединение в памяти
* Доменные события - публикуем на каждое изменение
* События как источник - храним сущности как последовательность событий, собираем цельный документ по событиям на чтении - потому что у них изменений много больше, чем чтений.
Не пишем сразу все микросервисы с однократным переходом, а переводим постепенно. Фаулер: если вы переписываете все и сразу, то у вас получится только сломать все и сразу.
Надо разделять deploy и release. После деплоя - проверяем в продакшене, но пользователей не запускаем. Можно откатить. И только после проверки - релиз, с плавным переводом пользователей на новый сервис. Постепенный переход позволяет увидеть проблемы. Например, больше сервисов - больше сетевых взаимодействий - могут появиться проблемы, их увидим. А еще можно решить, что целей достигли до того, как полностью выключили монолит и оставить его.
Шаги изменения, на примере выделения отправки документа и файла от из интернет-банка в банковские системы исполнения.
* Собрали отправку файла в отдельный компонент file-sender внутри монолита
* Поставили перед отправкой файла отдельный интерфейс
* Сделали собственный отдельный сервис на основе выделенной отправки файла
* Поставили в интерфейсе переключатель: используем встроенный компонент или вызываем внешний сервис
* Переключаем, проверяем
* Убираем отправку файла из монолита.
Работа с данными на переходе. Для обкатки - можно напрямую обратиться к БД монолита. Потом - определяем данные, их передаем в API, делаем отдельное хранение.
= Татьяна Яковлева. Инструменты для визуализации данных: от простого к сложному =
Хорошая личная история развития аналитика: от анализа данных в Excel к созданию там дашборд, подключенного к базе данных и далее - к дашбордам на python dash. Вывод: все доступно, дорогу осилит идущий, на этой дороге сложностей нет, а где есть, например, с CI/CD - разработчики помогут.
{{wl-publish: 2023-05-16 11:38:00 +0300 | MaksTsepkov }}