代码是敲出来的吗？是批量生成出来的吗？

　　No no no，代码是设计出来的！

　　如果说到代码生成器，大家可能会想到三层、动软代码生成器、数据库表等等。其一般的思路是，先有数据库然后根据库里的表自动生成一系列的代码，包括实体类、持久化、业务层（空函数）、页面代码等，还可以生成数据库文档。这个确实很好很强大，可以免除程序员的机械式的敲代码的工作。

（“主要实现在对应数据库中表的基类代码的自动生成，包括生成属性、添加、修改、删除、查询、存在性、Model类构造等基础代码片断,支持不同3种架构代码生成，使程序员可以节省大量机械录入的时间和重复劳动，而将精力集中于核心业务逻辑的开发。”

——摘自动软官网的介绍　　）

　　但是我们都知道，表的设计是根据客户的需求、业务逻辑、设计人员的项目经验设计的，其中最主要的是要受到关系型数据库自身的特点（所以nosql嘛）。表并不能完整体现业务需求，否则教会客户使用企业管理器（数据库的客户端软件）就可以了。直接把表交给客户用，那是不行的，否则程序员就集体失业了。

　　总结一下，一般代码生成器的思路是：数据库表——代码——文档。

　　而我这里说的思路是完全相反的：文档——代码——数据库——业务逻辑

　　一般我们做项目的顺序是：调研，设计，编码，测试，上线。其中设计阶段要编写大量的文档，比如功能说明，各种流程图，领域设计，数据库设计，原型图等等。还要编制任务计划，团队分工合作。然后开始编码。编码的时候会发现，上一阶段的各种文档只能看，对于要编写的代码完全没有直接作用，必须要程序员进行“翻译”。把文档翻译成代码——于是乎苦逼的码农诞生了！

　　而实际情况是，项目紧任务重时间还短。怎么办呢？文档可以没有或者后补，但是代码是不能没有的，所以往往文档就被忽略甚至完全被干掉了——这是文档和代码的矛盾点。

　　怎么办呢？牺牲文档？下面要介绍一把双刃剑：可以让文档成为代码的助力！可以把码农从简单、机械、重复中解脱出来，但是同时也意味着不会再有“码农”这个岗位！

　　还要从刚进入的这家公司说起。公司主营各种企业管理的项目，采用ABP架构最为底层，然后又进一步封装。

 　　简单的说，用EF的code frist做实体类，然后生成数据库，再根据业务需求设计Dto，有很多很多的Dto。页面用angularjs做总控和表单，kendoui做列表。存储部分至少定义一个接口，webapi部分也要定义一个接口。总之面向接口编程嘛。还有很多很多，逐步了解中。

　　对于新人来说，最大的问题就是——这都哪跟哪呀。有了code frist，也就没有了数据库文档。有一大堆dto，但是这些dto都是啥功能？点开挨个看吧。

　　看了两周还是蒙登。如果有一系列的文档说明该多好？但是大家都知道，任务紧工期短，哪有时间弄文档？

 　　好了又绕回来了，如果我们设计的文档可以自动生成代码，是不是一切就都迎刃而解了呢？

　　数据库角度：先设计数据库文档，然后自动生成ef的code first 的实体类，然后用ef的数据库迁移功能建立表。然后生成默认的接口定义。这个没啥难度吧。

　　业务角度：设计功能模块、页面，页面里面的数据列表、查询、分页、删除、表单等，然后根据这些设计生成对应的Dto，以及相关的接口，还有页面需要的代码。这样代码和文档就都有了。

　　怎么样，一份设计实现两种功能（文档和代码）。这时候基本功能就都出来了。然后在生成的代码基础上做一些调整和优化，主要是页面方面。

　　最后每个项目总会有些特殊的需求，我们就可以集中精力干掉它们了，

　　对了，还可以生成测试用例，还有测试人员使用的测试平台也可以结合起来。

　　现在您相信了吧：代码是设计出来的！

文档驱动式代码设计器——代码是设计出来的！