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

Question

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

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

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

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

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

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

Я думал о том, как я мог бы сделать:

1. Идея
2. Осуществлять
3. Тест
4. ПЕРЕЙТИ К №1

Для моих коллег ездите на велосипеде максимально легко, быстро и безболезненно.

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

С самого начала я посмотрел на встраивание:

• Луа (полезно гид)
• Питон (полезно гид)

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

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

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

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

Answer 1

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

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

Answer 2

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

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

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

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

Answer 3

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

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

Answer 4

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