为什么要手动生成代码？

当生成代码是最优选择的时候，那么整个系统必然在某些地方有问题。

• 可能是开发者的代码水平缺陷
• 可能是编程语言设计缺陷
• 可能是框架缺陷

开发者的代码水平缺陷

你的代码的维护者只拥有平均的技能水平。

语言缺陷

比如java的equals和hashCode方法，重写它们实在太标准了以至于IDE都支持自动生成对应的方法，那么为什么不把这种重写做成声明式的，添加到语言规范里面呢？

框架缺陷

例如，为什么从WSDL文件生成java代码而不是字节码？因为后者更复杂，更难以维护。

什么时候生成代码？

• (BC) before compilation
• (DC) during compilation
• (DT) during the test phase
• (DCL) during class loading
• (DRT) during run-time

Before Compilation

这个时候是最方便的。代码生成器读取配置或者源代码，然后将生成的代码一般放在特定的文件夹，与手写的代码分开。
这种情况下，生成的代码不纳入版本控制。跳过代码生成器，手动维护生成的代码不是一个好的选择。
生成的代码与编译器不是100%兼容的。

During Compilation

Java允许创建注解处理器供编译器使用。它们能在编译阶段创建代码并且交给编译器编译。
这个阶段的代码生成器无法访问编译后的代码，但是通过java编译器提供给注解处理器的API，生成器可以指导编译结构。
这个阶段可以生成新的类，但是不能修改已经存在的源代码。

During the Test Phase

后面细说（原作者利益相关）

During Class Loading

在类加载的过程中可以修改代码，这类程序叫做Java Agents。它们在字节码层面修改已经编译了的代码。

During Run Time

运行时也可以生成java字节码并加载到对应的应用中。也可以生成源代码，编译后加载到JVM。

Generating Code in Test Phase

Geci就在这个阶段生成代码。
这个阶段代码已经被编译了。
考虑一个重写equals和hashCode方法的类，如果删除了一个字段，那么编译器会报错，但是如果增加了一个字段，开发者很有可能忘记在这两个方法里面添加新增的字段。
那么在测试阶段将预期的equals方法与已经存在的equals方法进行比较，如果不一致，那么使用预期的equals方法复写原来的equals方法。

（对Geci不是很感兴趣，后面没有看了。原文链接：https://www.javacodegeeks.com/2019/04/generate-source-code.html