Упрощение алгоритма тестирования для исследователей.

Question

Я работаю в группе, которая занимается комплексным исследованием и разработкой полного кода доставки.

Половину времени я разрабатываю процессы, которые выполняются в нашей системе реального времени (где-то между мягким реальным и жестким реальным, средним реальным?)

В другой половине я пишу или оптимизирую процессы для наших исследователей, которым совсем не нужен код.

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

Существует исследовательская версия для одной группы и производственная версия, которую иногда нужно будет объединить с исследовательским кодом, чтобы получить новейшую и самую лучшую версию для производства.

Чтобы протестировать эти процессы, вам необходимо настроить полусложную среду тестирования, которая будет отправлять анализируемые нами данные процессу в нужное время (система реального времени).

Я думал о том, как сделать:

1. Идея
2. Реализовать
3. Тест
4. GOTO # 1

Цикл как можно проще, быстрее и безболезненнее для моих коллег.

Одна из моих идей заключалась в том, чтобы встроить язык сценариев в эти длительные процессы. Таким образом, по мере выполнения процесса они могут настроить фактический алгоритм и его параметры.

С бита я посмотрел на вложение:

• Lua (полезно , гид )
• Python (полезно руководство )

Они оба кажутся выполнимыми и могут фактически полностью решить данную проблему.

Есть еще какие-нибудь яркие идеи?

Перекомпиляция после смены 1-2 строки, повторное развертывание в тестовой среде и перезапуск просто отстой.

Система довольно сложная, и, надеюсь, я объяснил это наполовину прилично.

Answer 1

Если вы можете изменить достаточно программы с помощью скрипта, чтобы она была полезной, без полной перекомпиляции, возможно, вам следует подумать о том, чтобы разбить систему на более мелкие части. Вы можете иметь «сервер», который обрабатывает загрузку данных и т. Д., А затем клиентский код, который выполняет фактическую обработку. Каждый раз, когда система загружает новые данные, она может проверить и проверить, был ли клиентский код перекомпилирован, а затем использовать его, если это так.

Я думаю, что здесь будет пара преимуществ, самое большое из которых будет то, что вся система будет намного менее сложной. Теперь вы работаете на одном языке вместо двух. У людей меньше шансов запутаться, когда они переходят из режима python или lua в режим c ++ в своей голове. Встраивая в систему какой-то другой язык, вы также рискуете стать зависимым от него. Если вы используете Python или lua для настройки программы, эти языки либо становятся зависимостью, когда наступает время развертывания, либо вам нужно возвращать вещи в C ++. Если вы решите портировать вещи на C ++, у вас есть еще один шанс для ошибок возникать во время переключения.

Answer 2

Встраивание Lua намного проще, чем встраивание Python.

• Lua была разработана с самого начала для встраивания; Встраиваемость Python была установлена ​​после факта.

• Lua примерно в 20 раз меньше и проще, чем Python.

Вы не много говорите о своем процессе сборки, но сборка и тестирование могут быть значительно упрощены с помощью действительно мощной версии make. Я использую mk Эндрю Хьюма, но вам, вероятно, было бы еще лучше потратить время на освоение nmake Гленна Фаулера, который может добавлять зависимости на лету и устранять необходимость в отдельной конфигурации шаг. Обычно я не рекомендую nmake, потому что это несколько сложно, но совершенно ясно, что Фаулер и его группа встроили в решения nmake много проблем масштабирования и переносимости. Для вашей конкретной ситуации это может стоить усилий, чтобы справиться с этим.

Answer 3

Это звучит так, как будто вам нужно CruiseControl или что-то подобное; каждый раз, когда вы касаетесь базового кода, он перестраивает и перезапускает тесты.

Answer 4

Не уверен, что понимаю вашу систему, но если сборка и развертывание слишком сложны, может быть, вы могли бы автоматизировать это? Если развертывание будет полностью автоматическим, решит ли это проблему?

Я не понимаю, как язык сценариев решит проблему? Если вы измените свой алгоритм, вам все равно нужно перезапустить расчет с самого начала, не так ли?