Как мы пишем софт для трейдеров (+ВИДЕО БОНУС)

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

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

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

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




Лет 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.
Ну и в качестве бонуса, как и обещали, прикладываем видео, которое мы сделали буквально пару дней назад.
 

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

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