06 марта 2019, 14:40
Вопрос тем кто пишет роботов
Как-то вы отдельно записываете логику программы, блок схема может, или в виде теста, что б через некоторое продолжительное время вспомнить что да как и почему именно так, что б не запутаться и в случаи ошибки быстрее найти причину?
примеру из вашей практики буду благодарен
Nikolai Panasenko, а покатитесь вверх или вниз? или у вас будет долгий боковик;))
максимально безопасный шорт до 2200₽
не ирр
TriAngle
11:41
Всем, добрый день!
Акции компании ALRS как правило растут в период с 14.06.-14.07, средний рост 7,76% из 10 лет в 8 случаях.
Auximen, Где ты тут увидел критику снятия предупреждения с МММшника Майтрейда? ))))
Ты злоупотребляешь свои проложением и откровенно врешь… что не так ??)
Мало того модератор меня истерично мин...
Европлан на Т
이익, в ВТБ пока ничего не начислили.
Я аж икнул, когда на размер портфеля посмотрел, и грешил на дивгэп Мосбиржи.
Но нет, просто списали расписки со счета
11:38
Александр Васильев, котировки с профинанс теперь рулят
Только вот со счетами ситуация остаётся непонятной
11:38
Всем, добрый день!
Акции компании SBER как правило растут в период с 14.06.-14.07., средний рост 3,42% из 15 лет в 12 случаях.
Пока рисуешь блок схему, сразу вылезает много подводных камней, которые на бумаге сразу и решаются.
Igr,
вот в Visio я подобные отчеты себе рисую с блок схемами (там одна есть)
https://cloud.mail.ru/public/t68c/moEkBWbp9
Это вопрос прямо отсылающий к архитектуре.
Универсальных решений здесь нет.
Но имеются относительно стандартные подходы.
Чтобы грамотно декомпозировать программу нужно иметь представление как минимум о базовых паттернах.
На эту тему рекомендую https://www.ozon.ru/context/detail/id/2457392/
Определяете какие сущности должны быть представлены, как они будут взаимодействовать(интерфейсы), используете паттерны и будет вам счастье.
Но должен предупредить, что прочитать книгу, понять и освоить — это 3 разные вещи.
Между которыми может пройти не один год.
Вспоминать устройство программы гораздо проще, разбирая стандартные конструкции(шаблоны).
Документация и комментарии сами собой разумеются.
Каждый файл отвечает за свою задачу.
Иногда, если алгоритм сложен, я пишу огромную простыню развернутого текста — что, как, куда писать, откуда брать. Фактически, пишу программу, но на русском языке. Потом вычитываю.
Потом начинаю писать код прямо между абзацами этого текста, а текст превращаю в комментарии.
Вот так иногда и получается, что в файле из 500 строк — кода только строк 20-30. Зато он предельно понятен, даже если поднять его через 5 лет.
p.s.
Помнится, какбэгоботу я этого всего объяснить так и не смог — этот рукожоп предпочитал присылать код без единой строчки комментариев.
Андрей К, ну может у него и есть экземпляр с коментами
я например думал если робота поставлю на сервер куда то, то надо поудалять коменты, что б тяжелее было кому то разобраться))
Пишу комментарии, чем больше тем лучше. Плохой коммент лучше никакого. Пишу и долго обдумываю название функций и объектов.
Названия получаются длинные, выглядят неэстетично, но потому легче вспомнить.
Использую рефакторинг и агрессивно выношу куски кода в отдельные модули-файлы.
Короткие названия приживаются из-за закомплексованности адептов. Они в своем стремлении показать мнимую лаконичность экономят на каждой букве.
На самом деле это обезьяний стиль. Он больше всего у нас заметен в перле и хаскеле, к слову. Причем, если перл действительно сахарнолаконичный, то в хаскеле каждую такую лаконичность кучей свистоперделок еще надо снабдить.
В целом, даже сокращать ничего не надо. Надо писать полностью все слова.
И это самый лучший вариант. И читаемость выигрывает, и коллизий имен нет, и грамматику более или менее можно использовать, дисциплину имен.
У вас получается много-много 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.ошибка в коде (опечатки или пропуски каких-то строк например)
Ошибка логики как раз и находится по блок-схеме.
То есть можно получить на выходе работающую программу и даже не заметить что она делает не совсем то, что хотел разработчик. И не факт что ошибка логики вылезет быстро, если не будет ошибок в коде то ошибка логики может и через год только выявиться или даже позже.
Хотя если вести логи операций программы, то ошибка логики может быть выявлена довольно быстро.