Прошел полный месяц торгов, и мой робот показал +60%
В прошлом посте я просил у вас лайки, на данный пост я потратил 6 часов, которые мог бы потратить на что-то другое. Если вы хотите увидеть следующий пост, где мы уже будем подбирать параметры для нашей торговой системы. С вас 50 лайков :)
Сам я НЕ программист, мне нравится, когда мне рассказывают все по шагам. Бродя по интернету я нашел блог Игоря Чечета, который выложил небольшой курс по старту в backtrader: https://finlab.vip/wpm-category/btquikstart/
Я просто просмотрел все видео и повторял каждый шаг. Нет никакой магии. Просто смотрите и повторяете у себя.
Еще раз, для тех, кто читает слишком быстро: Просто смотрим видео, повторяем действия и у вас все получится.
В этой статьи я опишу 3 варианта создания роботов.
На самом деле вариантов очень много, тут опишу только свой опыт.
OsEngine
плюсы:
все в одном. Можно скачать дату, сделать бэк тесты и запустить в лайв из одного софта. Это очень удобно.
минусы:
Тяжело для новичков.
Нужно знать C# чтобы сделать своего робота, C# я знаю плохо и он мне не нравится.
Открыл, понажимал кнопочки, повспоминал C# и понял, что я не готов опять программировать на C#. Скорее всего это какие-то флешбеки из института. Но мне просто не нравится этот язык программирований.
Заниматься тем, что вам не нравится это плохо…
TradingView + Wonderbit
Как это работает смотрим пост №2.
плюсы:
очень просто написать и протестировать стратегию.
минусы:
очень сложно запустить 10+ роботов. (из опыта)
Чистая архитектура — продолжение беседы с легендарным дядюшкой Бобом о взглядах на искусство разработки программного обеспечения.
Идеальный программист и Чистый код — легендарные бестселлеры Роберта Мартина, рассказывающие, как достичь высот профессионализма. Чистая архитектура продолжает эту тему, но не предлагает несколько вариантов в стиле «решай сам», а объясняет, что именно следует делать, по какой причине и почему именно такое решение станет принципиально важным для вашего успеха.
Поговорим о дизайне и архитектуре. По мнению автора между этими терминами нет большой разницы, за исключением контекста применения.
Об архитектуре говорят в контексте общих рассуждений, когда не затрагиваются низкоуровневые детали. Дизайн же обычно подразумевает организацию решений на низком уровне. С этим высказыванием можно поспорить, потому как в наше время слова дизайн и архитектура часто лежат в разных областях разработки программного обеспечения, но рецензия не об этом.
Цель архитектуры программного обеспечения состоит в уменьшении человеческих трудозатрат на создание и сопровождение системы. Автор обращается к реальному примеру из практики
На первом графике мы можем видеть экспоненциальный рост инженерно-технического персонала, который работает над продуктом одной известной компании. С переходом к новой версии (1 — 8) увеличивается число сотрудников участвующих в разработке и обслуживании системы
В следующих разделах книги идет разговор о парадигмах программирования. Автор делает обзор на три из них:
структурное
объектно-ориентированное
функциональное
Каждая парадигма накладывает свои ограничения, ни одна не добавляет особенных возможностей.
Фактически последние полвека мы учились тому, как не надо делать
Важнейший раздел, на котором я рекомендую основательно остановиться как начинающим так и опытным программистам — Принципы дизайна. Также мы их можем узнать по известной аббревиатуре SOLID.
В интернете вы можете найти множество статей с подробным и поверхностным описанием этих принципов, но в этой книге я увидел совсем другие формулировки, которые больше относятся не непосредственно к коду и примерами на одном из языков программирования, а к целым архитектурным паттернам.
Многое осталось непонятым. Считаю, что к некоторым откровениям я еще не готов в силу недостаточного опыта в разработке. Поэтому обещаю вернуться к прочтению этих глав в ближайшие пару лет.
Например, первый из принципов — принцип единственной ответственности традиционно гласит, что модуль должен иметь одну и только одну причину для изменения, но что или кто есть причина? Автор предпочитает называть причину — актором, в качестве которого выступают группы пользователей вашего приложения, у которых могут быть свои причины для внесения правок в разрабатываемую систему. В качестве осязаемого примера, я бы привел разделение акторов смартлаба на читателей, писателей и комментаторов. Каждому из акторов отводится особенный функционал и при построении системы это необходимо учитывать.
Далее мы пробегаем по всем остальным принципам, которые автор не раскрывает до определенной реализации на каком либо языке, но достаточно хорошо соотносит абстрактные понятия с реальными примерами.
К сожалению (а может и к счастью) в книге приводится множество отсылок к технологиям “древнего” программирования, когда в качестве носителей еще использовали перфокарты. Это интересно читать с исторической точки зрения, но если вы хотите черпать новую информацию из книги, эти абзацы можно смело пропускать.
После обсуждения принципов SOLID книга набирает обороты в стороны абстракции, и я не могу сказать, что вынес пользу из прочтения “средних” глав книги — видимо снова проблема в опыте. Такой информационный перегруз мне еще не по зубам.
Однако в конце книги меня ждал приятный сюрприз, в котором автор призывает нас не думать о деталях при построении архитектуры. Какую базу данных выбрать? Какой фреймворк использовать? Какой сервер? Консольное приложение или веб?
Это такие мелочи, которые пока нас не заботят. Мы решим этот вопрос позже
Однако я с уверенностью могу сказать, что настоятельно рекомендую прочесть первые две главы всем, кто участвует в мире разработки программного обеспечения: от начинающих программистов, аналитиков, тестировщиков до проект-менеджеров и руководителей самого высшего звена. Считаю, что именно в первой части содержится неоспоримая истина об управлении любым ИТ подразделением.