我的自动化编程

记录一个想法，不是今天才想。

这只是我的自动化编程，如果有读者不小心看到这篇文章，请不要把它想得很高大上。

因为我已经实现了在thinkphp3.1.2下半自动生成标准的CURD代码，可以给视图带上既定样式，给控制器方法带上相应的RBAC权限验证，自动生成RBAC节点的SQL，最后将生成的代码自动保存为相关程序文件。

我对此并不满意，虽然我对它进行了几次优化和改进，它从一开始就被我设计的有5个代码编辑框可以在一个web页面上不用切换文件就能立即修改指定代码块，现在还能够将保存过的代码项目再次在这个编辑器中打开（是的我把它当作一个编辑器了），为它甚至还考虑了一些安全因素和操作体验以便我的同事也能够使用。

在开发一些功能模块的时候，它已经被我自己用过好几次了，我相信它的准确性和稳定性，也知道他的缺点因为他是我调教出来的学生，至于我的同事们用过多少次，我没有问过，不过我知道他们用过。

然而它只是基于我们公司内部常用框架的一个辅助工具，它不能够被外部使用，只能在我与同事之间的小环境内，为了在特定任务下提高效率才使用一下。虽然它自动生成的代码有时不需要通过修改可以直接上线，但因为业务的逻辑往往需要将他生成的代码进行一些修改才能达到目的，而它生成的代码是基于我预先设置的代码模板，是不包含任何业务逻辑的。当然了正是基于它自动的生成了标准的CURD代码，才使得我可以专注于添加和修改少量的业务代码即可完成目标。

我还是要重复一遍我对它并不满意。

不是不算满意，是不满意。

虽然我的同事对于这个东西表现了一丁点兴趣，以及友好或客套性的向我表达了些许称赞，并同意了这个东西可以一定程度的提高效率的观点。

也许是因为它是我的第一个学生，它诞生于一个初级的需求，虽然它诞生之时我对他的未来也有很高的期望，但现在将他回炉改造不合时宜，而我的脑子里已经孕育了一个未来会比它更好的第二个学生。

它们是连形状都不具备的物品，它们不会对我有感情，只有我在为它们付出，那么我必然为更有前途的那个想法付出更多，并立停止向老版本的想法继续付出，我现在停止为老版本付出不会带来任何后果。

对，就是版本的概念。我的第二个学生将是一个全新的版本，它将基于一个全新的架构和最新的理念，因为它的师兄，我的第一个学生，让我明确了在一定场景下的全自动编程的想法完全可行，基于它（我的第二个学生）的可行，我可能未来还会去调教第三个、第四个或者第五个学生，去实现全自动的编程，以及自动编程场景的自定义化，代码模板的自定义化，当自定义的场景足够多，最终将实现“不同场景下的全自动编程”。

我的第二个学生，我可能不会急于将自定义场景自动编程的重任交给它，因为我抓住了自动编程的重点：需求与数据结构。

需求是软件价值的表达，数据结构是结合软件需求与软件构架后所产生的软件的“形状”。

根据软件需求自动形成架构方案和数据结构并不是我现在的目标，它是自动编程的高级阶段，不过我相信我最终将实现它。

我认为自动编程的最终阶段是根据完整的需求（当需求不完整时协助你完善你的需求）自动创建方案，并为选用的方案自动编写代码，自动编译或部署，当然还是以场景为概念，当你需要在哪种场景下让它自动编程，那么你需要为它去建立它应对这个场景时的需求分析、方案构建、组件选用、代码编写等各种处理过程，只需要建立一次便可让它永远学会这种场景下的自动编程，你还可以为你构建的这个场景进行升级，那么它也随着你对这个场景的升级而提高应对这个场景自动编程时的“段位”。

这个最终阶段是我的目标，然而我知道一定要以一个开放的态度才能实现这个伟大构想，我说这是个伟大的构想你赞成吗？

可能有人会想象，会不会有一天，软件的需求都不需要人类去定义，直接由人工智能来根据已知或挖掘的社会问题来自动生成需求并最终生成程序？

我相信未来可能会有人提出类似的概念并作出尝试，但是，我也不知道怎么描述，只能说人类科技的快速发展并不意味着未来人类的大脑只需要有一个乒乓球那么大就够了，人类在解决了自身社会问题后接下来所要面对的可能是更艰难的任务。如果人类为了免去一些思考而让机器产生了自主思维，这是一个很未来，很科幻的概念，而在现在的概念里，我只认为：程序帮助人类完善需求并最终将需求所需要的程序功能自动实现，已经是自动编程的终极阶段。

下面是对我第二个学生的调教的打算：

mysql 表注释最大长度为2048字符数，字段注释最大长度为1024字符数

实现一个网页建模工具，在其中可以建立数据库、数据表、字段及索引

在这个建模工具中对表与字段的注释进行扩展管理，如下：

1、利用数据表的注释存储json形式配置该表的功能性信息（控制器、功能名称、模型、视图列表）

2、利用字段注释存储json形式字段功能性配置（字段中文名、显示顺序、是否必填、验证规则、dom类型、联表或数据序列）

以上注释内容，可以特定边界作为协议，由扩展程序进行设置和获取。

它的好处在于每个表和字段的配置信息在其自有注释里面然，可以随着数据表结构的导出而带走，而这样的方式需要为mysql允许的注释长度能否满足所有场景的配置内容而担忧。

不过，如果我们把配置信息会随着数据表结构的导出而带走视为安全性问题，那么，应该选用以下方案：

创建专用表：zhwj_autoDB_，直接将以上配置类信息存储到表中，该表的字段结构可以更加的多样性，不用担心长度不够，使用扩展插件对该表进行处理更加清晰。

无论哪种方案（当然我已经选定了后者），配置的信息将用来为程序的自动化编程提供指示，比如每个表所对应的功能模块名称、每个字段所对应的中文名称、字段的数据序列或外键信息等等。当基于这个数据库建模工具完整的创建了数据库之后，便可以让程序扫描遍历并根据每个表的配置信息执行自动编程，那么一个项目（web管理后台）中的标准CURD代码就全部完成了，程序员只需要将宝贵的时间专注在业务处理上。

虽然我真正动手去实现自动编程之初只是为了解决标准CURD，以现有的条件也只能解决标准CURD，但我对它的寄望远不止于止，正如以上所说，它最终可能让很多人感到惊讶，甚至惊慌。

记录一个想法，不是今天才想