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

 

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

 

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

 

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

 

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

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

 

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

 

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

 

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

 

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

 

　　而实际状况是，项目紧任务重时间还短。怎么办呢？文档能够没有或者后补，可是代码是不能没有的，因此每每文档就被忽略甚至彻底被干掉了——这是文档和代码的矛盾点。

 

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

 

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

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

 

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

 

　　看了两周仍是蒙登。若是有一系列的文档说明该多好？可是你们都知道，任务紧工期短，哪有时间弄文档？

 　　好了又绕回来了，若是咱们设计的文档能够自动生成代码，是否是一切就都迎刃而解了呢？

 

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

 

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

 

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

 

　　最后每一个项目总会有些特殊的需求，咱们就能够集中精力干掉它们了，

 

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

 

　　如今您相信了吧：代码是设计出来的！