шаблоны проектирования — Написание C ++ «Скрипты»

Я сольный разработчик большой библиотеки C ++, которую я использую для исследований (я аспирант). Допустим, в библиотеке есть несколько классов, которые реализуют классные алгоритмы: Algorithm1, Algorithm2и т. д. Затем я пишу набор функций в стиле C, которые представляют собой автономные «скрипты», которые используют библиотеку для тестирования недавно добавленной функциональности или для запуска симуляций, которые создают графики, которые я затем включаю в удивительно блестящий (I ‘). м в опровержение) журнальных публикаций. Дизайн библиотеки следует хорошим принципам разработки программного обеспечения (насколько я знаю и насколько я знаю), но «сценарии», которые связывают библиотеку с main.cpp не следуйте никаким принципам, кроме: «сделай работу».

Теперь у меня есть более 300 таких «сценариев» в одном файле (более 20 000 строк кода). У меня нет проблем с этим, я остаюсь очень продуктивным, и это действительно конечная цель. Но мне интересно, есть ли у этого подхода серьезные недостатки, с которыми я только что научился жить.

// File: main.cpp

#include <cool_library/algorithm1.h>
#include <cool_library/algorithm2.h>
...
#include <cool_library/algorithmn.h>

void script1() {
// do stuff that uses some of the cool library's algorithms and data structures
// but none of the other scriptX() functions
}

void script2() {
// do stuff that uses some of the included algorithms and data structures
}

...

// Main function where I comment in the *one* script I want to run.
int main() {
// script1();
// script2();
// script3();
...
script271();

return 0;
}

Изменить 1: У меня есть несколько целей в этом процессе:

• Минимизируйте время, необходимое для запуска новой функции скрипта.
• Сделайте все старые функции скрипта доступными на кончиках пальцев для поиска. Поэтому я могу скопировать и вставить биты этих скриптов в новый. Помни это НЕ должен быть хорошим дизайном для использования другими.
• Меня не волнует время компиляции файла скрипта, потому что он компилируется менее чем за секунду, как сейчас с 20 000 строк кода.

Кстати, я использую Emacs в качестве своей «IDE», в Linux, используя процесс Autoconf / Automake / Libtool для сборки библиотеки и сценариев.

Редактировать 2: Исходя из предложений, я начинаю задумываться, не является ли одним из способов повышения производительности в этом сценарии не реструктуризация кода, а настройка / расширение функциональности IDE (в моем случае Emacs).