我在一个从事大量研究开发和完整运输代码的小组工作。
我有一半时间开发在我们的实时系统上运行的流程（介于软实时和硬实时之间，中等实时？）
另一半我为那些根本不关心代码的研究人员编写或优化流程。
目前我正在研究一个我必须分成两个不同分支的过程。
一个小组有一个研究版本，一个生产版本需要偶尔与研究代码合并，以将最新和最好的投入生产。
要测试这些流程，您需要设置一个半复杂的测试环境，它将我们分析的数据在正确的时间（实时系统）发送到流程。
我正在考虑如何制作：
让我的同事尽可能轻松、快速、无痛地骑行。
我的一个想法是在这些长时间运行的进程中嵌入一种脚本语言。因此，随着流程的运行，他们可以调整实际算法及其参数。
我立即查看了嵌入：
这些似乎都是可行的，实际上可能完全解决给定的问题。
还有其他好主意吗？
在 1-2 行更改后重新编译，重新部署到测试环境并重新启动很糟糕。
该系统相当复杂，希望我能体面地解释它。
如果您可以通过脚本更改足够多的程序以使其有用，而无需完全重新编译，那么也许您应该考虑将系统分解为更小的部分。您可以有一个“服务器”来处理数据加载等，然后是执行实际处理的客户端代码。每次系统加载新数据时，它都会检查并查看客户端代码是否已重新编译，如果是，则使用它。
我认为这里有几个优点，其中最大的优点是整个系统不会那么复杂。现在您使用一种语言而不是两种语言工作。人们在脑海中从 python 或 lua 模式转移到 c++ 模式时，不太可能把事情搞砸。通过在系统中嵌入一些其他语言，您也会冒着依赖它的风险。如果您使用 python 或 lua 来 tweek 程序，这些语言要么在需要部署时成为依赖项，要么您需要将事情退回到 C++。如果您选择将内容移植到 C++，则在切换期间还有另一个机会出现错误。
嵌入 Lua 比嵌入 Python 容易得多。
Lua 从一开始就被设计为嵌入式；Python 的可嵌入性是事后嫁接的。
Lua 比 Python 小约 20 倍，也更简单。
您不会对构建过程说太多，但是通过使用真正强大的 make 版本可以显着简化构建和测试。我使用 Andrew Hume 的mk，但您可能最好花时间掌握 Glenn Fowler 的nmake，它可以即时添加依赖项并消除对单独配置步骤的需要。我通常不推荐 nmake，因为它有点复杂，但很明显，Fowler 和他的团队已经为许多扩展和可移植性问题构建了 nmake 解决方案。对于您的特定情况，可能值得努力掌握它。
不确定我是否了解您的系统，但如果构建和部署过于复杂，也许您可以自动化它？如果部署是完全自动的，那会解决问题吗？
我不明白脚本语言如何解决问题？如果你改变你的算法，你仍然需要从头开始计算，不是吗？
听起来您需要的是CruiseControl或类似的东西；每次你接触基线代码时，它都会重新构建并重新运行测试。