网上学习资料一大堆,但如果学到的知识不成体系,遇到问题时只是浅尝辄止,不再深入研究,那么很难做到真正的技术提升。
一个人可以走的很快,但一群人才能走的更远!不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人,都欢迎加入我们的的圈子(技术交流、学习资源、职场吐槽、大厂内推、面试辅导),让我们一起学习成长!
命名包
- 简洁明了: 包名应简短、有意义,通常为单数形式,避免使用下划线或混合大小写。
- 不使用common或util: 避免创建名为
common
、util
或helpers
的包。这类包通常聚合了多种不相关的功能,不利于代码的组织。 - 一致性: 包名应与目录名保持一致。若包名为
json
,则其目录结构也应为/path/to/json
。
常用的一级包名
在Go项目中,合理命名一级包名对于保持代码的整洁和可维护性至关重要。以下是一些常见的一级包名及其用途的简要说明。
- cmd: 用于存放项目的主要应用和可执行文件的入口。在一个项目中,可能会有多个应用,每个应用都会在
cmd
下有自己的目录。 - pkg: 包含可被外部应用使用的库代码。这些代码应设计为可重用的,而不是项目特定的。
pkg
目录是一个惯例,用于明确哪些代码是安全导出的。 - internal: 包含私有的应用代码和库代码。这些代码只能被该项目内部其他代码所引用。使用
internal
包是一个好方法,来确保我们的公共接口清晰且有意图地被设计。 - api: 包含定义外部公共API的协议定义文件,如OpenAPI/Swagger
规格、gRPC的.proto
文件等。这些定义文件可以被外部系统使用,以确保API的一致性。
- web 或 server: 用于存放处理HTTP请求的处理器(handlers)和路由逻辑。如果我们的应用提供Web界面或API,这些代码通常位于这个包下。
- client: 包含用于与外部服务交互的客户端库,例如HTTP客户端、数据库客户端等。
- config: 用于存放应用配置相关的代码。这可能包括解析配置文件、环境变量的逻辑。
- service 或 app: 通常包含应用的核心业务逻辑。这里的代码实现了应用的主要功能。
- model 或 domain: 包含应用的数据模型或领域模型。这些模型定义了应用数据的结构和行为。
- store 或 repository: 用于数据持久化相关的代码,例如数据库访问逻辑。
- util 或 helper: 包含辅助函数和工具代码,这些代码可以跨项目共享。不过,建议尽量避免创建一个庞大的
util
包,而是根据功能进一步细分。
- 尽管这些包名是常见的,但并不意味着每个项目都必须使用它们全部。根据项目的具体需求选择合适的包名和组织结构。
- 在使用
pkg
和internal
目录时,重要的是要保持一致性,并确保代码的组织方式对团队成员来说是清晰和直观的。 - 有效的代码组织策略应该能够随着项目的发展而灵活调整。在项目早期,可能不需要非常复杂的目录结构,但随着项目的成长,合理地重构代码组织结构是必要的。
遵循这些最佳实践可以帮助我们创建清晰、可维护的Go项目,同时也能提高代码的可读性和团队的协作效率。
包的层次结构
合理的包层次结构有助于提升项目的可读性和可维护性。
- 领域驱动设计(DDD): 根据业务领域来组织代码,每个业务领域一个包,如
order
、customer
、inventory
等。 - 分层架构: 在项目中按照MVC(Model-View-Controller)或类似的模式组织代码,如将数据模型(Model)、业务逻辑(Service)、接口逻辑(Controller)分别放在不同的包中。
- 内部包: 使用
internal
包限制包的导出范围。位于internal
包中的代码只能被同一个父目录下的代码所引用,这有助于封装。
网上学习资料一大堆,但如果学到的知识不成体系,遇到问题时只是浅尝辄止,不再深入研究,那么很难做到真正的技术提升。
一个人可以走的很快,但一群人才能走的更远!不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人,都欢迎加入我们的的圈子(技术交流、学习资源、职场吐槽、大厂内推、面试辅导),让我们一起学习成长!
IT行业的老鸟或是对IT行业感兴趣的新人,都欢迎加入我们的的圈子(技术交流、学习资源、职场吐槽、大厂内推、面试辅导),让我们一起学习成长!**