Нестабильность работы: Несмотря на то, что мои алгоритмы работают преимущественно с рыночными заявками (тип заявок, который предполагает 100% исполнение), мои позиции часто удваивались, либо не исполнялись вовсе.
Может быть вы не обрабатываете ответы брокера о результатах размещения заявки? Когда я занимался разработкой автоматизированных средств торговли через IT Invest, используя их SmartCom такая проблема возникала именно в случае игнорирования результата обработки заявки брокером.
Брокер может отклонить заявку по многим причинам. Несоответствие цены заявки текущему диапазону цен торгов, остановка торгов, заявка не дошла до брокера вовсе.
Задваивание позиции как правило происходит если торговый алгоритм повторно срабатывает в момент, когда первая заявка на открытие позиции еще не исполнилась (не дошла до брокера), а торговый сигнал по прежнему обнаруживается алгоритмом.
Бывали кстати и случаи, когда брокер не присылал подтверждение получения заявки, как будь то она до него не дошла (возможно произошел сетевой сбой), а потом все же исполнял ее.
В случае сильного движения на рынке кстати, исполнение даже рыночной заявки может значительно задерживаться и это тоже может влиять на дублирование позиции.
В общем как показал мой опыт, процесс обмена заявками с брокером следует реализовывать в исчерпывающем виде. Обрабатывая абсолютно все события:
Отправка
Подтверждение доставки заявки брокеру
Отсутствие подтверждение доставки заявки брокеру (запрашивать брокера о состоянии ранее отправленной заявки, чтобы понять знает ли он о ней)
Получение информации о сделках
Получение информации об изменении размера своего депозита у брокера
А куда девалась типизация в JS? Почему вы считаете что в JS нет интерфейсов?
В сыром JS дизайн если он изначально в каком-то виде существовал, то очень быстро обесценивается тк он не подкреплен компилятором.
То есть вы считаете что в интерпретируемых языках с динамической и утиной типизацией дизайн как понятие в принципе отсутствует?
Ну то есть к примеру возьмем мы и напишем программу на языке C, запустим компилятор и он ее откомпилирует успешно. Означает ли это автоматически наличие хорошего дизайна в компилируемой программе?
Что вы вообще подразумеваете под понятием дизайн, если предполагаете что компилятор способен обеспечить его наличие?
Agile, в долгосрочной перспективе как раз позволяет быстрее получать качественный результат. За счет автоматизации, за счет всеобъемлющего тестирования, за счет повторного использования кодовой базы. Проблема в том, что у собственников софтверных бизнесов "нет денег" на долгосрочную перспективу.
Потому гибкие практики (Agile) были придуманы для того, чтобы достигать технического совершенства. А кого в наше время это интересует?
Я много раз собеседовался в разные компании, разрабатывающие и собственные продукты и подвизающиеся на ниве аутсорса. Большинство из них считают что у них есть Agile-Scrum, и в то же время все они сообщили мне что готовы мириться с массой ошибок в своем программном обеспечении, главное чтобы оно было выпущено в срок.
Лишь в одной из сотни интервьюировавших меня компаний сообщили что их разработчики всегда сначала пишут модульные тесты.
Ну я же спросил не про общие принципы, а именно про инженерные коммуникации. Вы написали:
Во время коммуникации каждый понимает все по-своему, интерпретирует как-то иначе, нежели чем было сказано.
Если посмотреть в сторону традиционных инженерных практик, таких как электротехника или машиностроение, то там есть формальные инструменты в виде чертежей, принципиальных или монтажных схем.
Когда у вас в руках чертеж с указанием проекций, разрезов, размеров и допусков вы более-менее однозначно понимаете чего же от вас хочет ваш коллега или заказчик. Чертеж — вполне себе эффективный инструмент инженерной коммуникации, неплохо зарекомендовавший себя за сотни лет эксплуатации. Поэтому при подготовке инженеров принято развивать навыки разработки и чтения чертежей.
А если вы программист? Что вы можете использовать в качестве формального инструмента коммуникаций эффективностью не хуже чертежа? Что лично вы используете? Что использует ваша команда?
Я бы сказал, что оно применимо, но при одном дополнительном условии, которое автор не сформулировал достаточно четко.
Описанный способ хорошо работает, если разбиение происходит на задачи, объем каждой из которых достаточно мал, скажем часы.
У меня была мысль, в дополнение к утверждению:
Во-вторых, требуемый функционал достаточно четко ограничен в объеме используемых данных и во времени.
Добавить рассуждения на тему количества значений переменных, используемых в операции, но мне показалось что это опять же приведет к размыванию основной идеи.
Если вы это можете сделать для игр или CAD — это даст реалистичную оценку.
Я не смогу сделать это для игр или CAD, ибо это не моя предметная область. Однако я полагаю, что если руководитель проекта, управляющий разработкой игр или CAD, совместно с разработчиками, программирующими в этой же сфере будет постоянно, осмысленно и осознанно практиковать описанные мной в публикации действия, то точность оценки будет постепенно нарастать.
Да. Именно это я и имел в виду, когда написал что прежде, чем взяться за планирование рефакторинга 10К кода, надо потратить время на исследование этого кода.
Как разработчик, я хочу рефакторить 10 тысяч строк кода — это слишком масштабная история. И если к примеру с этим кодом никто не знаком из разработчиков, то прежде, чем взяться за планирование, надо потратить время на исследование этого кода. Потому что — как планировать неизвестность?
Если бы мне пришлось управлять таким рефакторингом, я бы не взялся сходу за прогнозирование затрат времени на всю реализацию целиком, а попробовал бы сделать это частями. Изучаем часть кода, пишем тесты, выполняем рефакторинг, прогоняем тесты.
А если требование «Как пользователь, я хочу оплатить заказ криптовалютой SuperPuper» SuperPuper версии 0.0.1 вышла вчера, документации нет, но разработчики утверждают что «SuperPupper is the most advanced and stable crypto currency ever. You can integrate SuperPupper with your website in under 5 minutes!» Сколько поставим часов на реализацию, 5 минут?
Я понимаю что 5 минут это утрированный пример. Как показывает опыт, даже если платежный шлюз действительно выдающийся, и у него исключительно понятная документация для разработчиков и она полностью соответствует действительности, и мы используем готовый виджет для отправки собственно платежа, то мы просто экономим какое-то время на пунктах исследований, коммуникации и разработки платежной формы, а остальные пункты из списка никуда не деваются. Так что нет, в любом случае не 5 минут.
Часы указаны в качестве примера того, как управляющий может сделать пометку о прогнозе запланированного времени в системе визуализации процесса управления. Это не сумма реальных часов, необходимых на реализацию оплаты пластиковой картой.
Я не вычислял время для статьи потому что при этом надо учитывать например платежный шлюз, с которым осуществляется интеграция. Текст бы сильно распух, и основная простая мысль, которую я хотел озвучить, размылась бы.
Как-то слабовато. Предложенные критерии разбиения на user story работают только для типичных crud и ecommerce. Попробуйте применить это для CAD, игр, научного или системного софта.
А почему нет?
Как AI, я хочу спрогнозировать направление следующего движения игрока
Как система, я хочу прочитать список команд устройства X
Как система моделирования освещенности, я хочу вычислить компенсацию отражения от плоской поверхности из материала Y
Так и есть. Любые пункты, подразумевающие коммуникации с третьими сторонами непредсказуемы по времени. Особенно если третья сторона за океаном, в другом часовом поясе и говорит на другом языке. Планы никогда не выдерживают встречи с реальностью, я написал это.
Главная мысль в том, что управляющий проектом должен заложить в график некий запас времени на эти коммуникации, чтобы по ходу пьесы понимать отчего время идет, часы расходуются, а функционал не реализовывается.
Вообще появление в списке задач пунктов, подразумевающих масштабные коммуникации, для опытного управляющего представляют собой сигнал о том, что необходим резервный план действий. И это отдельное искусство, потому что с одной стороны надо постараться избежать простоя в работе, с другой стороны не отморозить разработчиков постоянными переключениями между контекстами работы.
Может быть вы не обрабатываете ответы брокера о результатах размещения заявки? Когда я занимался разработкой автоматизированных средств торговли через IT Invest, используя их SmartCom такая проблема возникала именно в случае игнорирования результата обработки заявки брокером.
Брокер может отклонить заявку по многим причинам. Несоответствие цены заявки текущему диапазону цен торгов, остановка торгов, заявка не дошла до брокера вовсе.
Задваивание позиции как правило происходит если торговый алгоритм повторно срабатывает в момент, когда первая заявка на открытие позиции еще не исполнилась (не дошла до брокера), а торговый сигнал по прежнему обнаруживается алгоритмом.
Бывали кстати и случаи, когда брокер не присылал подтверждение получения заявки, как будь то она до него не дошла (возможно произошел сетевой сбой), а потом все же исполнял ее.
В случае сильного движения на рынке кстати, исполнение даже рыночной заявки может значительно задерживаться и это тоже может влиять на дублирование позиции.
В общем как показал мой опыт, процесс обмена заявками с брокером следует реализовывать в исчерпывающем виде. Обрабатывая абсолютно все события:
Странный ответ. А что еще в процессе разработки имеет отношение к дизайну, ну кроме компилятора?
Почему абстрактных?
Никуда и не девались.
Вы считаете что это основа дизайна?
А куда девалась типизация в JS? Почему вы считаете что в JS нет интерфейсов?
То есть вы считаете что в интерпретируемых языках с динамической и утиной типизацией дизайн как понятие в принципе отсутствует?
Ну то есть к примеру возьмем мы и напишем программу на языке C, запустим компилятор и он ее откомпилирует успешно. Означает ли это автоматически наличие хорошего дизайна в компилируемой программе?
Что вы вообще подразумеваете под понятием дизайн, если предполагаете что компилятор способен обеспечить его наличие?
А почему дизайн системы отсутствует при использовании голого JS?
Неужели использование TS автоматически привносит в проект хороший дизайн?
Agile, в долгосрочной перспективе как раз позволяет быстрее получать качественный результат. За счет автоматизации, за счет всеобъемлющего тестирования, за счет повторного использования кодовой базы. Проблема в том, что у собственников софтверных бизнесов "нет денег" на долгосрочную перспективу.
Потому гибкие практики (Agile) были придуманы для того, чтобы достигать технического совершенства. А кого в наше время это интересует?
Я много раз собеседовался в разные компании, разрабатывающие и собственные продукты и подвизающиеся на ниве аутсорса. Большинство из них считают что у них есть Agile-Scrum, и в то же время все они сообщили мне что готовы мириться с массой ошибок в своем программном обеспечении, главное чтобы оно было выпущено в срок.
Лишь в одной из сотни интервьюировавших меня компаний сообщили что их разработчики всегда сначала пишут модульные тесты.
Ну я же спросил не про общие принципы, а именно про инженерные коммуникации. Вы написали:
Если посмотреть в сторону традиционных инженерных практик, таких как электротехника или машиностроение, то там есть формальные инструменты в виде чертежей, принципиальных или монтажных схем.
Когда у вас в руках чертеж с указанием проекций, разрезов, размеров и допусков вы более-менее однозначно понимаете чего же от вас хочет ваш коллега или заказчик. Чертеж — вполне себе эффективный инструмент инженерной коммуникации, неплохо зарекомендовавший себя за сотни лет эксплуатации. Поэтому при подготовке инженеров принято развивать навыки разработки и чтения чертежей.
А если вы программист? Что вы можете использовать в качестве формального инструмента коммуникаций эффективностью не хуже чертежа? Что лично вы используете? Что использует ваша команда?
И как же нам повысить эффективность хотя бы инженерных коммуникаций в процессе разработки программных продуктов? Как это реализовано у вас?
На мой взгляд вполне.
У меня была мысль, в дополнение к утверждению:
Добавить рассуждения на тему количества значений переменных, используемых в операции, но мне показалось что это опять же приведет к размыванию основной идеи.
Я не смогу сделать это для игр или CAD, ибо это не моя предметная область. Однако я полагаю, что если руководитель проекта, управляющий разработкой игр или CAD, совместно с разработчиками, программирующими в этой же сфере будет постоянно, осмысленно и осознанно практиковать описанные мной в публикации действия, то точность оценки будет постепенно нарастать.
Да. Именно это я и имел в виду, когда написал что прежде, чем взяться за планирование рефакторинга 10К кода, надо потратить время на исследование этого кода.
Если это так, то возможно тот, кто управляет проектом, не делает свою работу или делает ее очень плохо?
Как разработчик, я хочу рефакторить 10 тысяч строк кода — это слишком масштабная история. И если к примеру с этим кодом никто не знаком из разработчиков, то прежде, чем взяться за планирование, надо потратить время на исследование этого кода. Потому что — как планировать неизвестность?
Если бы мне пришлось управлять таким рефакторингом, я бы не взялся сходу за прогнозирование затрат времени на всю реализацию целиком, а попробовал бы сделать это частями. Изучаем часть кода, пишем тесты, выполняем рефакторинг, прогоняем тесты.
Я понимаю что 5 минут это утрированный пример. Как показывает опыт, даже если платежный шлюз действительно выдающийся, и у него исключительно понятная документация для разработчиков и она полностью соответствует действительности, и мы используем готовый виджет для отправки собственно платежа, то мы просто экономим какое-то время на пунктах исследований, коммуникации и разработки платежной формы, а остальные пункты из списка никуда не деваются. Так что нет, в любом случае не 5 минут.
Часы указаны в качестве примера того, как управляющий может сделать пометку о прогнозе запланированного времени в системе визуализации процесса управления. Это не сумма реальных часов, необходимых на реализацию оплаты пластиковой картой.
Я не вычислял время для статьи потому что при этом надо учитывать например платежный шлюз, с которым осуществляется интеграция. Текст бы сильно распух, и основная простая мысль, которую я хотел озвучить, размылась бы.
А почему нет?
Так и есть. Любые пункты, подразумевающие коммуникации с третьими сторонами непредсказуемы по времени. Особенно если третья сторона за океаном, в другом часовом поясе и говорит на другом языке. Планы никогда не выдерживают встречи с реальностью, я написал это.
Главная мысль в том, что управляющий проектом должен заложить в график некий запас времени на эти коммуникации, чтобы по ходу пьесы понимать отчего время идет, часы расходуются, а функционал не реализовывается.
Вообще появление в списке задач пунктов, подразумевающих масштабные коммуникации, для опытного управляющего представляют собой сигнал о том, что необходим резервный план действий. И это отдельное искусство, потому что с одной стороны надо постараться избежать простоя в работе, с другой стороны не отморозить разработчиков постоянными переключениями между контекстами работы.
Согласен, Javascript гораздо интереснее… :-)