Как мы пишем софт для трейдеров

Очень многие пиарят свои программные продукты, упуская один важный момент – сам процесс разработки. Мы решили приоткрыть завесы тайны и рассказать о том, как создаётся софт для трейдеров.

В этом посте мы постараемся описать весь процесс разработки от идеи до конечного воплощения. В конце мы покажем видео того, что может получиться в результате, если начатое дело доводить до конца.

Существуют различные методологии разработки, но мы не будем вдаваться в подробности, т.к. тут это был бы совсем оффтопик и ознакомиться с ними можно на ресурсах вроде Хабрахабр. Мы же расскажем о том, как пишем софт для трейдеров на примере конкретного продукта – Журнал сделок.

Заваривайте чай (кофе), заворачивайтесь в плед и проходите под кат, где будет много букв и картинок. Поехали!




Лет 7-8 назад Андрей Беритц рассказал нам что такое скальпинг и показал пару рабочих паттеронов. В то время среди нашей тусовки считалось, что если за пару-тройку месяцев ты не научился скальпать по 5-10% в день, то ты явно делаешь что-то не так. Мы совершали сотни и иногда тысячи сделок вручную ежедневно.

Так как сделок было много, то нам был нужен софт, позволяющий анализировать эффективность торговли внутри дня. Нам на помощь пришёл Анатлий Павлов, разработав журнал сделок на макросах в эксле. Журнал был жутко медленный, а чтобы посчитать результат приходилось пересчитывать всё сначала. Каждый новый день мы начинали с чистого файла.

Выглядело это так:




В 2009 году, когда эффективность скальпинга снизилась, мы завязали с торговлей и засели за разработку торгового движка. Мы тогда не имели ни малейшего понятия о таких вещах как системы управления проектами и системы контроля версий. Но тем не менее через 2-3 месяца нам удалось написать первый торгующий двиожок на квике. Ещё через пару месяцев появлась пару рабочих стратегий и пошли первые копеечные доходы.

Мы быстро приспособились и наши алгоритмы стали генерировать сотни сделок в день. Мы, конечно, немного адаптировали тот самый журнал в экселе под наши новые потребности (анализ различных стратегий на одном тикере), но производитльность экселя оставляла желать лучшего. Таким образом, мы пришли к необходимости создания своей системы для анализа сделок трейдера.

К этому времени у нас в команде было 4 человека и мы имели кое-какой опыт в разработке.

Что было у нас в арсенале:
— знание с++
— знание фреймворка Qt
— опыт работы с системой управления проектами redmine
— опыт работы с системой контроля версий SVN
Итак мы пристпили к разработке.

Прежде всего стоит сказать о ролях людей в разработке проекта. Роли чисто условные и в маленькой команде человек может выполнять несколько ролей одновременно.

Мы использовали три:


  1. Менеджер
  2. Разработчик
  3. Тестировщик

Кроме этого стоит сказать, что у проекта могут быть вложенные подпроеткы. Так, например, для проекта Журнал Сделок (Trade Journal) подпроектом является модуль импорота данных из файлов Trade Importer.

Задача менеджера была понять что наиболее востребовано в команде и какие задачи надо прежде всего решить. Например сначала нужно было сохарнить сделки в базу, затем расчитать трейды, после этого учесть валютную составляющую индекса РТС, затем комиссию биржи и брокера… Этот список можно продолжать бесконечно.

Как появляются новые задачи? Очень просто, их создают пользователи.

Мы общаемся с пользователями через почту и в скайпе. Вот пример диалога:



Менеджер заходит систему управления проектами и создаёт новую задачу:



Теперь задача назначена разработчику alexey. Дата выполнения 4 августа 2013 года. Менеджер ожидает, что на разработку задачи уйдёт 2 часа.

Задача появлется в общем списке:



В этом же списке видно, что 3 другие задачи уже решены, но пока не закрыты, т.к. тестировщик их ещё не проверил.

Разработчик видит в редмайне новый тикет и приступает к реализации. Так выглядит среда разработки Qt Creator, в которой мы пишем журнал:



После того, как задача будет решена, разработчик сможет залить её в хранилище-репозитарий (сделать новую ревизию) и можно будет поставить ей соответсвующий статус.



В системе управления проектами есть ещё несколько фич, заслуживающих внимание. Прежде всего, это даграмма Ганта. Анализируя её можно понять какие задачи находились дольше всех в разработке и вообще увидеть свой процесс разработки в графическом виде:



Кроме этого, в системе управления проектами можно получить доступ к репозитарю проекта – специализированному хранилищу версий проекта:



Эта же система позволяет смотреть отличия между двумя разными ревизиями проекта:



На скриншоте выше видно, как мы улучшили логгиование подключения к терминалу транзак. В новой версии кроме самого сообщения о подключении мы записываем в лог адрес, порт и логин (само собой без пороля) с которым пользователь подключается.
Также перед разработкой новой версии создаётся оперативный план, к которому прикрепляются задачи:



Из скриншота видно, какие задачи будут  реализованы в новой версии 1.4.


Мы с удвольствием ответим на ваши вопросы и и почитаем рассказы о том, как работают другие разработчики софта для трейдеров в комментариях!

Спасибо за внимание!







13 комментариев

avatar
Я тоже немного поделюсь опытом и расскажу, что поможет избавиться от ошибок в коде на 95% — это TDD и итеративный подход. Походу в трейдерском деле о таком вообще никто не знает, что странно — вроде не мешки картошки считаем. Самое лучшее что я встречал, стокшарп — и тот имеет дизайн, недружественный к модульному тестированию -> длительному циклу разработки.
avatar
Расскажите как вы пользуетесь TDD на практике (если можно пример какой-нибудь из жизни приведите)? 
 
Что качается итеративного подхода, то это классная тема. У нас копятся тикеты по проекту пару месяцев, а потом нахрапом за пару-тройку недель решаем все сразу.
 
avatar
Как я пользуюсь — очень просто, это моя профессия :) Все мои проекты покрыты тестами. Я могу вводить и выводить разработчиков из команды, в любое время забыть про проект и вернуться к нему через несколько лет, могу даже писать код пьяным — тесты показывают где я начудил. А пример какой вас устроит? Скриншот, где я что нибудь ломаю, а тест указывает точно где поломка? Ну вот, например, WMA поломаю


А теперь починю
avatar
А можно на код этих двух ошибочных тестов глянуть? 
 
Как правило о TDD говорят именно джава разработчики. Тут даже в среду разработки JUnit встроен. 
Просто не совсем понятно как это применять на плюсах.
Ну протестировать класс  и функцию понятно как. Написал, запустил в мейне скормив в функцию нужные аргументы, проверил результат. Но ведь для полноценного TDD, мне придётся писать целые классы тестов, да ещё и интегрировать их в проект, что его сильно раздует.
 
У нас есть опыт поиска ошибок через тестирование, но тесты писались под конкретную ошибку. В общем как поставить это на поток и с чего начинать совершенно не понятно.
avatar
же писал вам в на почту, свои пожелания, вы  отвечали что добавили в список задач, но пока к сожалению не реализованно, посему дублирую свое пожелание к журналу: хотелось бы иметь возможность, видеть изменение счета в % на сделку и за период в %, а также иметь возможность видеть прибыль/убыток в пунктах на 1контракт( лот) на трэйд, и за период в дневнике тоже в пунктах в пересчете на 1 контракт(лот), а не только в деньгах как реализовано сейчас.
avatar
 а также иметь возможность видеть прибыль/убыток в пунктах на 1контракт( лот) на трэйд


Это реализовано. Смотрите столбец пункты в трейдах.


Что касается изменения счёта в %, то тут пока ещё не добрались. Скорее всего будем осенью делать. Пункты в дневнике скорее всего тоже осенью, пока малость дургм занимаемся.
avatar
Хотелось бы еще в дневнике в пунктах на 1 лот, и еще нужнее в раздел сводная прибыль/убыток  в пунктах на 1 лот.
avatar
Согласны. Добавим тикет для сводной.
А на счёт дневника, то понятно что на 1 лот, иначе каша вообще поолучится.
avatar
Благодарю Вас, надеюсь на оперативную реализацию.
avatar
На плюсах тоже можно, но посложнее из-за деструкторов. Смартпоинты сильно полезны. Я использую gtest/gmock. Тесты гораздо больше самого класса и это как правило считается основным минусом TDD. Но тесты в сборку не идут, и для проектов длительного цикла ценность теста увеличивается со временем. Когда проект разрастается, вы можете делать безопасные рефакторинги. А при ватерфоле обычно знаете наверное: тут поправил, там отвалилось. Еще очень важно, что TDD улучшают дизайн кода: никто не хочет писать длинные тесты, все хотят короткие. Но когда тест написать надо, здесь иного выхода как делать правильные зависимости обычно нет. К тому же, если ваш программер справляется с тестами, вы вообще представить себе можете, его работоспособность? Это зверь! :)



Тесты получаются большими из за количества кейсов в основном. Как видим, в этом случае два кейса охватываются схожими тестами, а там в верху (на скрине не видно) просто shared фикстура «правильной» WMA, с которой и выполняется сравнение.

PS. Начинать как и всегда — с малого. Начните покрывать возникающие ошибки и частные случаи. Сначала не все, затем подсядете.

Вот еще, в догоночку тест на плюсах

Последний раз редактировалось
avatar
Спасибо большое, всегда приятно открывать для себя что-то новое. 
В Qt Creator, кстати, тоже есть шаблоны проектов юнит тестов. На досуге займёся экспериментами.
avatar
  • demo
  • 0
Все это хорошо, но MaxProfit лучше по всем параметрам лично для меня, конечно. Я много чего пересмотрел и зарубежного и нашего.
avatar
  • demo
  • 0
упс… ссылочку забыл www.mxprofit.ru/
Последний раз редактировалось

Добавить комментарий