Comments 15
Покажите как будет выглядеть в коде обработка 3х состояний, например, processPayment (успех, отказ, обнаружен фрод).
Ветки обработок каждого этого состояния как будут выглядеть в коде?
Это не состояния, это результат некоторого вызова. В какие состояния он приведёт, зависит от того, что мы захотим. Пойдёт в один шаг, в другой или третий.
т, зависит от того, что мы захотим. Пойдёт в один шаг, в другой или третий.
покажите псевдокод, в котором успешная оплата переводит статус оплаты заказа в "оплачено", а в случае если от банка приходит отказ, то статус оплаты заказа не меняется, а выводится ошибка.
судя по той одной большой цепочке вызовов, что я увидел в статье, это будет проблемой.
или нет?
Перейти в нужное состояние после получения некоторого результата на конкретном шаге - не проблема. Для этого каждый шаг заранее объявляет возможные типы результата выполнения шага, на основании значения которого выбирается следующий шаг.
Если говорить о том, что при этом показывается пользователю, то у нас для процесса есть метод, который транслирует текущее содержимое контекста процесса (вместе с текущим шагом) в ответ, который видит пользователь. Пока мы находимся на некотором промежуточном шаге - мы возвращаем Операция в обработке, когда же мы оказываемся на одном из финальных шагов - то начинает глубже анализировать контекст процесса и сообщаем об успехе или причине ошибки (причина не является шагом, хранится отдельно в контексте, т.к. от нее не зависит топология процесса).
Отличный подход!
А ещё в момент перехода из одного состояния в другое можно собирать различные описатели (категориальные и числовые) и потом, после создания ML-модели, использовать их для прогнозирования вероятности перехода. Использование перечислимого множества имён (enum) для переходов, фичей, дескрипторов, с зашитым внутрь enum-константы поведением, очень сильно снижает вероятность ошибок, позволяет декларативно описать всё в одном-единственном месте. Длинно иногда получается, но не сильно страшно) Делал и использую подобный подход, кому интересно, смотрите тут (github, Java)
И порядок этих шагов не всегда линейный.
Мы не сразу заметили, что наши процессы обычно почти линейные — шаги выполняются один за другим. И структура кода в этих огромных классах повторяла такие шаги. Но в жизни обычно всё немного сложнее, и вот мы начали делать процессы, в которых переходы стали нелинейными. По сути, наши конечные автоматы начали развиваться в более сложные структуры.
Скажите, как у ваших автоматов обстоят дела с параллельностью?
Хотелось бы увидеть продолжение статьи, отражающее данный аспект - какие сложности встречались, как решались, какие фишки были реализованы.
Каждый процесс выполняется в отдельном потоке, перед началом выполнения захватывается глобальный лок, чтобы процесс не начал выполняться в каком-то другом экземпляре приложения. Все данные процесса локальны для выполняемого потока, поэтому проблем с многопоточностью при обработке множества разных процессов нет.
И здесь императивный подход стал нам сильно мешать: каждый раз нужно было просматривать весь этот огромный код, чтобы понять, из какого состояния можно попасть в другое и как.
Нативный "getFunctionName" в помощь и "координаты" текущего состояния в любой момент определены 😌
Говорят, в отделе аналитики подпрыгивали вместе со стульями, узнав о возможности обозревать то, во что превращается в коде их техническое решение. 😁
Говорят, если SM перевести на Kotlin DSL, то и разрабы улетают в космос вместе со стульями
На каком языке описывать SM, нам не так важно, как иметь такой принцип построения этой SM, который обеспечит простую поддержку того, что уже сделано. Описание SM у нас строится просто, основную ценность для нас представляет код, ассоциированный с этой SM, который решает бизнес-задачи. Там кода многократно больше, но теперь он не перемешан с кодом логики SM. И это облегчает написание логики на любом языке программирования.
Ваша статья показывает, что конечно-автоматный подход в программировании очень продуктивен. Я применяю его с 1981 года, и у меня он уже вылился в методологию программирования, которую я анонсировал в своей статье в 2021 году:
https://habr.com/ru/articles/554014/.
К сожалению, меня неправильно поняли и жестко встретили на Хабре, но несмотря на это работа над методологией успешно продолжается: https://t.me/ecoprog.
Удачи вам в ваших разработках с применением конечно-автоматного подхода.
Как и автор, занимались платежами с конечными автоматами, писали правда на Perl, про это есть доклад на ютубе https://youtu.be/GEykpn6IgAA .
Да, видно что вы примерно те же проблемы решали.
У нас поход от практики. Сделали нечто, увидели что решает наши задачи, стали убирать обнаруженные проблемы и подводить под описание автомата, которое будет обладать нужными нам свойствами (валидация, читабельность, лаконичность). И дальше то, что в статье описано.
Эволюция конечных автоматов в бэкенд-разработке