好问题。它与遗传算法概念、自动错误检测和持续集成有关。
早期的遗传启发算法
1990 年代的一些剑桥 LISP 代码刻意朝着自我完善的方向努力,这与自我修复不同,但两者是概念上的兄弟姐妹。
其中一些早期的 LISP 算法是受基因启发的,但不是通过有性生殖自然选择对 DNA 突变的纯粹模拟。这些类似进化的算法中的一些基于固定的有效性模型评估了它们自己的有效性。有效性模型将在运行时接受报告的客观指标并对其进行分析。当分析返回的有效性评估低于最小阈值时,LISP 代码将执行此过程。
- 复制自身(这在 LISP 中很容易)
- 根据一些元规则改变副本中的算法
- 将突变作为生产模拟并行运行一段时间
- 自行检查突变的有效性
如果突变被认为更有效,它将执行四个无私的步骤。
- 记录自己
- 附加自己的性能以供以后元规则使用
- 将它创建的突变加载到自己的位置
- 执行细胞凋亡
与生物细胞凋亡不同,这些算法中的细胞凋亡只是将计算资源和运行时间控制传递给加载的突变。
这个过程在 LISP 中曾经并且可能仍然比其他语言更容易,尽管其他语言的爱好者会无休止地争论这一点。
持续集成的扩展
当错误报告与持续集成开发平台和工具集成时,这也是闭环持续改进策略。在当今的许多应用程序、框架、库、驱动程序和操作系统中,我们在自动检测提供的错误列表中看到了持续集成的扩展,特别是对于崩溃。闭环自我修复的许多元素已经在最先进的开发团队中普遍实践。
错误修复本身还没有像研究人员在上面的 LISP 代码中尝试的那样自动化。开发人员和团队负责人正在遵循与此类似的过程。
- 开发人员或团队负责人将错误(分配)给开发人员
- 开发人员尝试使用相应版本的代码复制错误
- 如果复制,找到根本原因
- 修复设计发生在某个级别
- 修复已实施
如果持续集成和适当的配置管理到位,那么在提交更改到团队存储库时,它将应用于正确的分支,并运行单元、集成和功能测试的测试套件以检测任何修复可能无意中造成的损坏。
几台全自动化已经投入使用
可以看到,许多部分都已用于自动算法、配置和部署包自我修复。甚至有几家公司正在进行项目,通过记录用户行为和用户对诸如“这有帮助吗?”之类的问题的回答来自动创建功能测试。
缺什么
什么需要进一步开发才能更完整地看到全生命周期的自我改进和自我修复软件?
- 自动错误复制
- 自动单元测试创建
- 自动修复设计
- 从设计中自动创建代码
下一步
我建议接下来要做的就是这些。
- 评估上述四个缺失的自动化已经完成的工作
- 审查可能在 1990 年代被搁置的 LISP 程序,或者可能没有,因为我们看不到(也不应该看到)什么被分类或使公司保密)
- 考虑过去二十年内出现的机器学习构建模块如何提供帮助
- 寻找利益相关者提供项目资源
- 开始工作
关于需求、道德和技术置换的说明
说实话,软件质量在 1980 年代、1990 年代、2000 年代和 2010 年代都是一个问题。就在今天,在执行该软件旨在执行的一些最基本功能时,我在被认为是稳定版本的软件中发现了十几个错误。
鉴于错误列表的大小,正如事故使人类是否应该驾驶汽车的问题成为问题一样,人类是否应该保持软件质量也是值得怀疑的。
人类已经在许多事情上幸存下来。
- 用铅笔和橡皮擦算术不见了
- 带车库工具的专业农业已经不复存在
- 使用 Exacto 刀具制作广告机械已不复存在
- 手动分拣邮件不见了
- 骑马快递沟通没了
很少有软件工程师乐于修复错误。他们似乎最乐于创建充满其他人应该修复的错误的新软件。为什么不让别人做人呢?