Обсуждение статьи "Проектирование конечного автомата торговой стратегии на MQL5: Замена вложенных конструкций if-else явными состояниями"

Новый комментарий

Опубликована статья Проектирование конечного автомата торговой стратегии на MQL5: Замена вложенных конструкций if-else явными состояниями:

Вложенные условные конструкции if-else внутри функции OnTick() создают неявные состояния, которые сложно изолировать, отлаживать и расширять без возникновения регрессионных ошибок. Реализация конечного автомата (FSM) на MQL5 использует интерфейс IState, посредник CStrategyContext и четыре конкретных состояния, чтобы отделить логику обнаружения от логики поведения. Структура из трёх подключаемых файлов устраняет циклические зависимости подключаемых файлов и чётко разделяет объявления, определения и создание экземпляров, делая внесение изменений безопаснее, а отладку — быстрее.

Разработка типичного советника (EA) начинается с функции OnTick(), в которой легко разобраться. Одно условие проверяет, открыта ли позиция, другое оценивает сигнал входа в рынок, третье проверяет приемлемость спреда, а четвёртое — активность торговой сессии. Четыре условия — понятные, наглядные и простые в отладке.

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

Корень проблемы в том, что у советника (EA) есть неявные состояния — ожидание, поиск сигнала входа в рынок, сопровождение позиции, управление выходом из позиции, но они закодированы разбросанными по коду комбинациями булевых флагов, а не представлены как отдельные явные состояния. При использовании неявных состояний код их обработки смешан с кодом определения границ между состояниями. В результате в каждой точке проверки функция должна отвечать на два вопроса: каково текущее состояние и какое действие следует выполнить. Это две разные сферы ответственности, и именно их совмещение делает код хрупким.


Автор: Ushana Kevin Iorkumbul

Новый комментарий