# 介绍

Gozz 由两部分组成：

gozz (opens new window) 是用户使用该项目的 cli 工具运行入口，包含了对用户命令的解析，插件的加载和实例化，以及对外部扩展的加载。
gozz-core (opens new window) 是核心依赖库，包含了代码文件解析，注解解析，结构化注解对象，运行时对象索引，缓存等核心功能依赖。同时为各个插件提供包含模版、生成、编辑、追加文件相关的工具依赖。

Gozz 包含一系列内置插件，致力于提供部分以往总结沉淀的技术性需求的工具化解决方案。

gozz-doc-examples (opens new window) 项目中包含了所有内置插件的基础示例，插件部分提供了对照阅读。

同时我们还提供了可根据需求自行选择的外部插件 (opens new window)。这些插件基于 Golang plugin (opens new window) 机制运行， Gozz 提供了自动化插件安装指令，用户可以自由地进行二次开发和接入。

风格

Gozz 强调可递进的幂等式生成，在用户项目需求不断变更的过程中，可以通过一致的命令和配置提供稳定的自动化代码迭代集成。

# 愿景

编程就是将 重复、繁琐的事情 ，将成熟的方案通过程序化实现高效、低成本、规范化地解决。

而我们的设计和开发过程中本身有很多工作，本身也是 重复、繁琐的事情。

在我们一遍又一遍地去浪费时间做这些低效开发时本身就违背了编程的初衷和思想。

Gozz 通过工具化希望助力 成熟技术方法论 和 优秀实践方案 传播和落地：

通过代码生成和编辑，提供最佳实践，或提供最佳实践的模板化入口。

最好的代码，是不用人人都重复写的代码

并希望大家由此能：

Less, But Better

会尽可能使用简洁和 符合人类直觉 的命令 / 注解 / 参数

首先，在使用 Gozz 之前，希望你能明确知道：注解不是Golang官方特性

不清楚这一点的开发者，我会建议先行通过其他教程进行学习 Golang。

然后，用好 Gozz 需要有一定的前置认知：

提示

如果你有使用 JAVA Spring 的经验，那么可以有一定的认知优势。

Gozz 解决需求的思路学习了 JAVA Spring 一些重要设计思想，但绝不是拙劣地模仿。

人月神话 中有 保有概念整体性 的说法这个系统设计理念也是笔者比较认同即：

系统的核心架构设计需要由少数人专制控制

因此，使用 Gozz 的时候，团队需要由一个核心的资深角色给出适合团队的 Gozz 配置以及维护生成模板和适配层。

在团队内，即使是不同的业务项目，在 Gozz 的使用都不应该产生过多分歧。

而其他成员只需要遵循团队的规范，将运行 Gozz 的指令写到项目 Makefile 或构建工具，在代码变更及提交之前去执行。

在确保生产稳定性后，Gozz 鼓励所有团队角色去主动探索和学习，如何去优化业务和项目的架构设计，用更低的成本办更多更好的事。

Gozz 也将会在项目示例中提供一些最佳实践供开发者们参考。

Gozz 的应用并不局限于微服务场景，相反，越大型的项目和协作团队，相信会越容易从 Gozz 中受益更多。

前世今生中有提到：一些内置插件的前身，就是为了优化数十万行级代码系统项目重构需求而生。

微服务，只代表个别服务在业务依赖领域设计中的 Micro / Pluggable / Extensible ，但从不意味着该项目代码架构层级和设计简单，或该服务维系人员较少。

如果你希望团队的微服务项目代码质量和协作效率能够得到一定的提升，也欢迎使用 Gozz 和我们提供的各个内置插件功能。