Системы самотестирования

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

И ваша идея одновременного запуска подпрограмм может ввести условия гонки.

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

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

Видел ли я подобную концепцию на практике? Нет. Но я все равно предложу подход.

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

CruiseControl может запускать модульные тесты для проверки правильности новой версии.

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

Если цикл сборки CruiseControl пройден, новая версия будет принята. Для реализации такого процесса потребуются значительные усилия, но я думаю, что это выполнимо. Модульные тесты и построитель тестов должны быть довольно хорошими.

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

Вы можете построить на их основе. Затем внедрите свой код в

1. разделить рабочие единицы на дискретные модули / классы (шаблон стратегии)
2. идентифицировать каждый модуль по уникальному имени и связывать с ним возможность
3. когда модуль запрашивается, он запрашивается возможностями, и случайным образом используется один из модулей с этой возможностью.
4. вести статистику производительности (получить системный тик до и после выполнения и сохранить результат)
5. если возникает исключение, отметьте этот модуль как неиспользуемый и зарегистрируйте исключение.

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

Я считаю эту идею интересной теоретической дискуссией, но не очень практичной по следующим причинам:

1. Чтобы убедиться, что новая версия кода работает правильно, вам необходимо иметь превосходные автоматические тесты, а это очень труднодостижимая цель, которую многие компании не могут разработать. Вы можете продолжить внедрение системы только после того, как будут выполнены такие автоматические тесты.
2. Весь смысл этой системы заключается в настройке производительности, то есть конкретная версия кода заменяется версией, которая заменяет ее по производительности. Сегодня для большинства приложений производительность имеет второстепенное значение. Это означает, что общая производительность большинства приложений адекватна - просто подумайте об этом, вы, вероятно, редко обнаруживаете, что жалуетесь на то, что «это приложение мучительно медленное», вместо этого вы обычно жалуетесь на отсутствие конкретной функции, проблемы со стабильностью, проблемы с пользовательским интерфейсом и т. д. Даже когда вы жалуетесь на медлительность, обычно это общая медленность вашей системы, а не только отдельные приложения (конечно, есть исключения).
3. Для приложений или модулей, для которых производительность является большой проблемой, способ улучшить их обычно состоит в том, чтобы выявить узкие места, написать новую версию и сначала провести тестирование независимо от системы, используя какой-либо тест. Конечно, может потребоваться также тестирование новой версии всего приложения, но в целом я думаю, что этот процесс будет происходить очень небольшое количество раз (следуя правилу 20% -80%). Выполнение этого процесса «вручную» в этих случаях, вероятно, проще и рентабельнее, чем описанная система.
4. Что происходит, когда вы добавляете функции, исправляете ошибки, не связанные с производительностью, и т. д.? Вы не получаете никакой выгоды от системы.
5. Запуск двух версий вместе для сравнения их производительности вызывает гораздо больше проблем, чем вы думаете - не только у вас могут быть условия гонки, но и если входные данные не являются подходящим эталонным тестом, вы можете получить неправильный результат (например, если вы получите много небольшие пакеты данных, и это в 90% случаев на входе - большие пакеты данных). Более того, это может быть просто невозможно (например, если фактический код изменяет данные, вы не можете запускать их вместе).

Единственная «среда», в которой это звучит полезно и на самом деле «обязательно», - это «генетическая» система, которая сама генерирует новые версии кода, но это совсем другая история и не очень широко применима ...

Идеи дизайна для систем высокой доступности можно найти в Erlang.

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

Что касается изменения на лету, я поделился своим вопросом и буду создавать его на основе Lua или аналогичного динамического языка. Могут быть части, которые загружены, и если они будут заменены, повторно загружены в работу. Никакого ракетостроения в этом тоже нет. Если «старый код» все еще работает, все в порядке, поскольку, в отличие от DLL, файл нужен только при его чтении, а не при выполнении кода, пришедшего оттуда.

Полезность? Неа ...