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

 

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

No no no,代码是设计出来的!

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

现在您相信了吧:代码是设计出来的!

来源:博客园

—— 完 ——
相关推荐
评论

立 为 非 似

中 谁 昨 此

宵 风 夜 星

。 露 , 辰

文章点击榜

细 无 轻 自

如 边 似 在

愁 丝 梦 飞

。 雨 , 花