code-generate是一个通用的代码生成工具，支持从各种元数据，通过定义模板生成必要的代码，减少低级重复的编码工作。目前支持通过数据库元数据生成业务对象、数据访问对象等。
项目地址
gitee: https://gitee.com/wei772/code-generate
github: https://github.com/wei772/code-generate
使用方法
- 设置模板堆栈，在 src/resources/templateRepository 目次下创建模板堆栈或使用现有模板堆栈，详情参考entityDemo堆栈
- 运行 mvn -U clean install 生成code-generate.jar包
- 使用Java17+运行jar包 大概单元测试TestCommandLineApplication大概 CommandLineApplication运行
- 使用entity代码生成工作类，并且使用jsonFileReader运行（该方式主要用于测试，不发起现实使用）
编写实体定义Json，参考definition.json
运行jar包
Windows下发起使用Cmd,PowerShell下面脚本运行有问题- java -jar code-generate.jar -Dtemplate.repository=entityDemo -Dgenerate.output=D:\source\code-generate\src\test\resources\generateResult -Dgenerate.basePackage=cn.cli -Dgenerate.author=liwei -Dgenerate.tags=mysql,jdbc -Dentity.reader=jsonFile -Dentity.reader.json.file=D:\source\code-generate\target\test-classes\entityGenerate\userDefinition.json
- java -jar code-generate.jar "-c=D:\source\code-generate\target\test-classes\config\json.properties"
运行jar包- java -jar code-generate.jar -Dtemplate.repository=entityDemo -Dgenerate.output=D:\source\code-generate\src\test\resources\generateResult -Dgenerate.basePackage=cn.cli.jdbc -Dentity.reader=jdbc -Dentity.names=user -Dentity.reader.jdbc.url=jdbc:mysql://localhost:3306/code_generate -Dentity.reader.jdbc.user=root -Dentity.reader.jdbc.password=123456
代码生成的最大优点就是减少低级重复的编码工作。
但是也有不少缺点。
- 起首它第一次生成容易，一旦修改过，生成就会困难很多。如果不修改生成代码可以减少影响
- 其次，尤其是比力重量级的生成容易促使开大家员直接使用生成的代码，而不是根据现实需求去调解代码
- 还有一个比力庞大弊端，会潜伏架构的垃圾设计，给垃圾架构打补丁。
- 比如一个实体生成几十个相干类，如果要手写只要是步调员就会拒绝这种垃圾架构，
但是如果有代码生成可能就勉强能接受。但是这样的架构是难以修改的，生成代码工具只会是温水煮青蛙，还不如不要。
- 很多看起来很有用的技术都存在同样的问题，比如依赖注入框架，很容易写出有复杂的依赖的类而不自知。技术手段无法拯救垃圾的设计，只会把问题潜伏的更深点，变得更严重
代码生成工具必要慎用，尽可能优化架构与设计，实在没办法避免的重复劳动才考虑使用。
测试驱动开发
本项目使用测试驱动开发的方法开发
效果与感受
流畅的组织所有开发活动的技术
测试驱动开发这种先写测试再开发的方式很流畅。
- 不要绞尽脑汁再脑中、用文字还有图去思考设计，这种方法浪费时间，想象力也无法有效发挥。
- 也不会一上来就编码，编写难以执行代码，代码根本没有设计，想到哪写到哪。
- 使用单元测试可以持续重构，一直保持设计和编码变得更好的
自底向上
本项目中体会到测试驱动开发是一种自底向上的设计和开发方式，从明确和渺小的方向开始一直到最复杂的问题，直到完成终极目标。
遇到新的并且复杂的事变，确实很难一下自顶向下给出比力完善设计方案，自底向上提供了一种一步一步办理部分问题，不停集成终极办理所有问题的方式。
依次在各个层次编码、设计、测试
测试驱动开发可以或许对一个概念在各个层级上都很好的测试、编码和设计,保证每个层次都最得当自己。例如targetLanguage就是从EntityType到Property以及Entity最后的CodeGenerate
从最高层到最低层测试。一旦那一层出现问题，只要看哪些测试用例异常都可以分析出哪里出问题，如果高层没有问题，那么问题就是最底层没有传好值，大概改动高层的值导致的。
然后targetLanguage相干设计，就有了Entity更新targetLanguage,PropertyType也会更新targetLanguage的实现，这能大大降级了调试时间
单元测试的代码代码量
单元测试的代码与实现的代码量差不多，某次统计代码行，实现 1714、单元测试 1400 （使用 IDEA Statistic插件统计）。
看起来增长了工作量，现实上却不是。减少了调试的时间，而且代码更加简洁，也是重构的基础，极大了减少了bug量。大大减少了开发和维护成本
测试驱动开发本质
下面一些经典数据的一些论述，涉及到测试驱动开发本质
《测试驱动开发 (Kent Beck) 》当中有几段话让我印象深刻，体现了这种方法的核心作用
- 而我从书籍上学到的却恰恰相反:“编码为今天，设计为明天。”而测试驱动开发看起来已经彻底推翻了这一论点: “为明天编码，为今天设计。” 。
- 测试(Test)--自动、具体、切实的测试。按一个键就可以让测试运行。具有讽刺意味的是测试驱动开发不是一种测试技术(Cunningham
Koan)。 它是一种分析技术、设计技术，更是一种组织所有开发活动的技术。
《敏捷整洁之道：回归本源》关于复式记账的论述
- 会计师们在1000年前发明了一条法则，并将其称为复式记账。每笔交易会写入账本两次:在一组账户中记一笔贷项，然后相应地在另一组账户中记为借项。
这些账户终极汇总到收支平衡表文件中，用总资产减去总负债和权益。差额必须为零。如果不为零，肯定就出错了
- 复式记账与TDD这两种纪律是等效的。它们都具有相同的功用:在极其重要的文档中避免错误，确保每个符号都正确。
只管编程对社会来说已经必不可少，
但我们还没有用法律强制实施 TDD。可是，既然编写糟糕的软件已经造成了生命财产损失，立法还会远吗?
步调
起首编写任务清单，一样平常包罗设计想法、要实现用例、重构任务等等，将TODO的事变要一个简朴的文档记载，整个过程比力随意，有价值的想法就记载下来，完成之后将对应的任务划上删除线。
然后是具体编写过程
- 从任务清单中挑选任务,针对任务编写不通过的单元测试，包括无法编译和运行错误的用例
- 使单元测试运行通过
- 重构现有代码，使设计更佳。
每次写代码都重复这3个步调，直到没有必要完成的任务。
包结构和主要类介绍
entity包
主要包罗实体定义相干类 Entity、Property和EntityType。
entity.reader包
实体代码生成读取实体设置
目前支持的设置范例
- jsonFile ,从json文件中读取设置的元数据
- jdbc ,使用jdbc从mysql与oracle等数据库读取元数据
template包
对应模板引擎和模板实例
目前支持的模板引擎有
param包
支持从设置文件中读取参数
- 支持@file参数,在文件里设置可以指定文件生成名
- 支持@folder，在文件里设置可以指定文件生成的目次,一样平常共同output参数使用。
generate包
代码生成核心类
- CodeGenerate,代码生成的生齿，读取所有代码生成相干参数
- CodeGenerateWork，真正去执行代码生成的工作类
- CodeGenerateWork具体实现类
- EntityCodeGenerateWork,通过实体设置读取模板文件生成相干文件
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。 |
