SMART-LAB
Новый дизайн
Мы делаем деньги на бирже
Информация
Блог им. Igr
Вопрос тем кто пишет роботов
- 06 марта 2019, 14:40
- |
Как-то вы отдельно записываете логику программы, блок схема может, или в виде теста, что б через некоторое продолжительное время вспомнить что да как и почему именно так, что б не запутаться и в случаи ошибки быстрее найти причину?
примеру из вашей практики буду благодарен
теги блога Igr
- Daimler AG
- ED
- qlua
- quik
- Si
- акции
- акция
- Арсагера
- бан
- банки
- башнефть
- биржа
- блок схема
- брокер
- вклады
- вопрос
- Вопрос всем
- время сервера
- ВТБ
- вымпел
- глюк
- ГМК НорНикель
- ГО
- график
- дивиденды
- дно
- доллар
- друзья
- ЕБС
- жопа
- завод
- иис
- индивидуальный инвестиционный счет
- инсайд
- Интер РАО
- инфляция
- капитализация
- кбробот
- Квик
- Коррупция
- кредит
- криптовалюта
- кукловод
- лонг
- ЛСР
- лчи
- манипулирование
- минусы
- ммвб
- ММВБ Акции
- мнение по рынку
- мусор
- Навальный
- налог
- налоговый вычет
- нелеквид
- обмен
- объективность
- одиночество
- опрос
- открытие
- офз
- оффтоп
- ошибка
- первый
- плюсики
- ПРАВДА
- правила Smart-lab
- Программирование
- программисты
- продажа
- производвство
- протест
- робот
- рост акций
- сбербанк
- свободные средства
- северсталь
- сервер
- сериал
- скорость
- смартлаб
- СССР
- стакан quik
- стоп
- ТА
- татнефть
- треугольник
- уфа
- ФА
- Финам
- фондовый рынок
- фортc
- фортс
- фундаментал
- фьюч
- фьючерс
- хлеб
- Энел Россия
- юмор
Пока рисуешь блок схему, сразу вылезает много подводных камней, которые на бумаге сразу и решаются.
Igr,
вот в Visio я подобные отчеты себе рисую с блок схемами (там одна есть)
https://cloud.mail.ru/public/t68c/moEkBWbp9
Это вопрос прямо отсылающий к архитектуре.
Универсальных решений здесь нет.
Но имеются относительно стандартные подходы.
Чтобы грамотно декомпозировать программу нужно иметь представление как минимум о базовых паттернах.
На эту тему рекомендую https://www.ozon.ru/context/detail/id/2457392/
Определяете какие сущности должны быть представлены, как они будут взаимодействовать(интерфейсы), используете паттерны и будет вам счастье.
Но должен предупредить, что прочитать книгу, понять и освоить — это 3 разные вещи.
Между которыми может пройти не один год.
Вспоминать устройство программы гораздо проще, разбирая стандартные конструкции(шаблоны).
Документация и комментарии сами собой разумеются.
Каждый файл отвечает за свою задачу.
Иногда, если алгоритм сложен, я пишу огромную простыню развернутого текста — что, как, куда писать, откуда брать. Фактически, пишу программу, но на русском языке. Потом вычитываю.
Потом начинаю писать код прямо между абзацами этого текста, а текст превращаю в комментарии.
Вот так иногда и получается, что в файле из 500 строк — кода только строк 20-30. Зато он предельно понятен, даже если поднять его через 5 лет.
p.s.
Помнится, какбэгоботу я этого всего объяснить так и не смог — этот рукожоп предпочитал присылать код без единой строчки комментариев.
Андрей К, ну может у него и есть экземпляр с коментами
я например думал если робота поставлю на сервер куда то, то надо поудалять коменты, что б тяжелее было кому то разобраться))
Пишу комментарии, чем больше тем лучше. Плохой коммент лучше никакого. Пишу и долго обдумываю название функций и объектов.
Названия получаются длинные, выглядят неэстетично, но потому легче вспомнить.
Использую рефакторинг и агрессивно выношу куски кода в отдельные модули-файлы.
Короткие названия приживаются из-за закомплексованности адептов. Они в своем стремлении показать мнимую лаконичность экономят на каждой букве.
На самом деле это обезьяний стиль. Он больше всего у нас заметен в перле и хаскеле, к слову. Причем, если перл действительно сахарнолаконичный, то в хаскеле каждую такую лаконичность кучей свистоперделок еще надо снабдить.
В целом, даже сокращать ничего не надо. Надо писать полностью все слова.
И это самый лучший вариант. И читаемость выигрывает, и коллизий имен нет, и грамматику более или менее можно использовать, дисциплину имен.
Eugene Logunov, спасибо
я один, самоучка
У вас получается много-много unit tests, которые в хорошей IDE запускается пакетом. Если вы модифицировали код, запустили тесты, а они не прошли — значит ваши изменения (коммит) с багами.
Для серьёзных проектов помогает.
Мне не подошло, много исследовательской работы на тяп ляп и в ней не до серьёзных подходов.
Serg Prismotrov, прога для теста прог? не, это слишком для меня
я в луа пишу, ищу ошибки через коменты которые выводит прога, и смотрю что там написано, какая из переменных например не верна
Даже свои собственные комментарии не так просто понять через годик-второй.
Вместо того чтобы на логике концентрироваться, будешь голову ломать как все лучше описать.
Это все ложная религия
push(myElement, myArray)// Here we pushed myElement to MyArray
сильно помогает
Комментарии обязательно, лучше один раз подробно закоментить чем потом часами ломать голову вспоминая что-то.
Имена переменных и констант придумываю так, чтобы по тексту программы было понятнее откуда ветер дует и от какого модуля переменная или глобальная, эти пометки в именах переменных зашиты в виде сокращения.
Иногда что-то рисуешь на бумажке, но не более того.
Мне помогают иногда физические модели и ассоциации. Ищешь какой-то аналог в реальном мире, и по нему делаешь.
Раз была задача реализовать генерацию строк без повторов, я лежал, думал, в итоге понял, что обычный счетчик электричества с механическим приводом делает то что мне надо, только вместо цифр надо буквы подставить
Блок схемы, это по-моему, детский сад какой-то. Для студентов примитивную логику объяснять годно, но на что-то большее едва ли.
Вообще Тру рекомендуют поменьше визуализаций разных. Даже визуальный текстовый редактор вредная роскошь:)
Если нужно что-то писать на быстром многословном, невыразительном языке, то можно взять язык прототипирования, который позволяет емко выражать логику. Подойдет пистон например.
Еще лучше самопис или DSL.
Идеально спроектировать язык под задачу, и решать эту задачу на этом специальном языке, а уже потом, либо шлифовать узкие места, либо переписать.
Это позволяет сконцентрироваться на логике и забыть о нюансах
Но это уже высший пилотаж. Это то, как должно было бы быть вообще в IT-инженерии, но не сбылось
Max, ) я на флешечку копирую)
но надо бы винт запасной иметь ....
0. Логику робота действительно важно строго сформулировать и зафиксировать на бумаге или файле.
1. на начальном этапе лучше И стол для бумаг, И стена для ватмана(-ов) и листков
2. обязательно папки «архив» и «идеи» как в бумажном, так и в компьютерно-облачном виде. Так сказать Ваше «детище» будет связано и с прошлым и с будущим. В Microsoft Visio или Microsoft Publiser обязательно вкладки с предыдущими блок-схемы логики проги. Диалектически, предыдущие версии могут быть лучше.
3. поддерживаю полное комментирование кода
4. поддерживаю блочность кода. Итоговая прога — сборка модулей-программ
5. проверка идей по очереди. Не вноси в блок-схемы и в код сразу несколько идей сразу. Одну внес-проверил-всё работает и работает как планировал, то делаем копию и только потом вносим изменения по другой идее.
P.S. Ну вот! Хотел наплюсовать ваш комментарий, чтобы вы так не расстраивались, а вы меня уже в бан отправили.
Для разворотных алгоритмов использую схемы в виде бабочек таких.
Идёт поток данных, используются состояния нахождения «робота».
Вначале состояние 0, нет позиций.
Основной цикл 0, 11, 12.
Предположим, имеется хороший признак, позволяющий ходить от 11 к 12 и обратно в среднем с прибылью. На рисунке наступление его обозначено e+.
Часто добавление трейлинг-стопа результаты ещё улучшает. На схеме состояния 13 и 14. То есть если прошли достаточно в нужную сторону (от 11 к 13), то дальнейшие события: разворот по признаку e+ (от 13 к 12) или стоп (небольшой выигрыш, от 13 к 0).
Вопрос в нахождении такого e+ и удостоверении в его надёжности.
Написал в коде первый блок — запустил — проверил как работает;
Написал в коде второй блок — запустил — проверил как работает;
И так далее...
Ошибки устраняются при тестировании каждого блока...
Затем система в целом…
1.ошибка логики (например определил контртренд а ошибочно перенаправил на трендовые входы)
2.ошибка в коде (опечатки или пропуски каких-то строк например)
Ошибка логики как раз и находится по блок-схеме.
То есть можно получить на выходе работающую программу и даже не заметить что она делает не совсем то, что хотел разработчик. И не факт что ошибка логики вылезет быстро, если не будет ошибок в коде то ошибка логики может и через год только выявиться или даже позже.
Хотя если вести логи операций программы, то ошибка логики может быть выявлена довольно быстро.
«я такой опытный строитель, что строю дома без проекта»
Не смешите.
На коленке можно делать только собачьи будки, а не дома.
Ну, есть и гении среди нас — эти могут всё.