Skip to end of metadata
Go to start of metadata

一、项目初心

GoFrame解决的核心痛点是Golang项目的工程化问题,她致力于建立一款由开源社区驱动的,满足高效、严谨、易使用、易维护特征的Golang开发框架,通过开源社区的形式让更多的人参与进来共同完善,将通用核心的基础组件从业务中解耦出来统一维护,而不用每个企业和团队都单独创建并维护重复性的轮子,毕竟这种轮子成本也不小,还很花费精力。

二、项目价值

GoFrame并不能解决所有的开发问题,请尝试先接触并了解一下她,如果她能为您的团队分忧解难,她就实现了价值。

三、项目背景

GoFrame项目开始得比较早,原本是公司内部孵化项目的一部分,用于企业内部使用的Go项目开发框架。由于需要给内部技术团队使用,并且鄙人深谙好的产品生命周期是20%的开发周期,80%的维护周期,因此降低入门成本,特别是维护成本是非常重要的一点考虑。所以GoFrame在设计上非常简洁,并且无论代码注释还是开发文档都写得非常详尽,且文档以中文为主,主要面向的是国内的团队和企业用户,以期降低开发人员的入门门槛、提高项目开发及维护效率。

GoFrame既是一款优秀的开发框架,也是一套高质量的基础组件集,这一切都是若干年日积月累的沉淀成果,难以一蹴而就,这也是其他Golang"框架"和"类库"难以企及和比拟的。

四、发展目标

1、工程化建设

GoFrame是面向工程化的,支持团队快速接入、高效开发、长期维护。针对业务型项目而言,提供工程实践的项目架构、设计模式、开发规范、开发工具、开发文档等团队开发与维护必需的基础服务能力。

2、基础组件建设

基础组件的研发,往往是短期投入、长期收益,投入产出比是最大的,因此GoFrame会长期不遗余力地加强对基础组件的研发建设。

3、团队企业为主

由于面向工程化,针对于团队开发协作来讲,可以将框架的服务能力价值最大化,因此GoFrame更适用于团队和企业用户。来源社区、回馈社区,鼓励团队和企业与开源社区良性循环共生。

4、社区生态共建

发挥和促进开源社区的能动性,繁荣GoFrame生态。

五、常见问题解答

1、GoFrame是个人项目还是企业项目?

个人项目,所以大家不用担心她是否为KPI而生,未来会发展为社区驱动项目。

项目雏形是来源于公司内部框架,但公司内部的开发框架不适合开源,主要并不是因为安全保密协议,而是原有的框架本身源码为了特定业务场景而设计,代码质量和文档资源也并不适合开源。目前的GoFrame框架源码根据原有的设计思想,基本上是全部重新编写的,代码质量比原有的框架高出了数个档次,并于2017年开源,开源后的发展迅速、超出预期。








Content Menu

  • No labels

5 Comments

  1. 感觉没有很好的发挥出golang的特性,组件化开发,但是发现还是很多的耦合,而且也用java的设计模式磨平了golang的特性

    1. 你说得偏主观,那我来猜测一下。

      第一点,我估计你可能说得是代码分层、对象封装、DAO这些玩意。不过这些是软件架构设计里面的概念,并不是Java里面的特性。有点软件设计经验的小伙伴应该都知道吧。这或许也是程序员、工程师、架构师之间的区别。

      第二点,我估计你想说的是把每个功能模块独立出来单独进行版本维护。goframe有个模块化设计的章节可以看看:模块化设计。并不是说完全剥离出来就是好的,也不是说一定要完全放在一个版本维护,这里面是有个度的,这个度需要软件架构师来把握,并不是一味的拆或者组合在一起。在我看来,并不是所有模块都应该在一个版本中维护,也不是把所有模块全部拆出来独立版本维护,这两者都是很极端的,后者为了解耦而解耦的痛苦我也经历过。这里有个图可以好好品味一下:

      goframe的价值是在于能够帮助你解决问题她就有价值,goframe从不宣扬她是最优的框架方案,一切以团队适合最重要。

    2. 亲亲你是否发现, 你使用任何语言的某一个依赖包的时候, 直接给你down下来一堆其他依赖, 亲亲是否发现, 为啥语言都有个 "依赖管理工具", 而不是包管理工具

  2. 请问有发展微服务的计划吗,我的项目目前使用的 SpringCloud ,想把项目迁移至 go项目,但是 go 目前微服务的资料比较少

    1. 有个微服务框架,只是还未发布:https://github.com/gogf/katyusha