软件行业和建筑行业比较像,如果说我们的产品是一栋高楼大厦,那么程序代码就是建筑高楼的砖坯(我们每天的工作就像是在不停"搬砖")。如果说软件架构是高屋建瓴,那么程序代码是软件架构能够准确落地的关键构成。
程序代码如此重要,那么开发框架的重要性不言而喻。开发框架着力于代码层面,解决通用性的技术问题,目的是使得开发人员能够将精力关注于业务本身、辅助软件架构能够快速响应业务变化、提高软件的整体开发和维护效率。
本章节我们主要介绍统一开发框架建设的意义和必要性。
在开始本章节之前,建议您先了解一下框架的:模块化设计 ,部分灵感和同感来源于:小马的经验分享
一、技术体系化
体系化更关注的是框架整体战斗力,而不是每个模块本身
框架体系化设计的显著特点:
- 体系完善、组件丰富
- 规范统一、风格一致
- 统一抽象、设计严密
- 执行高效,无重复逻辑
我们这里的体系化是指微观层面的代码开发框架自顶向下统一设计,使得整个框架的设计思想是一体的,而不是分散的。从技术上,解决一个具体的问题比较简单,开发一个特定的模块也比较容易,但是如何将共性的问题进行抽象沉淀、将各个独立的模块按照统一的设计思想组织协调,并产生强大的综合战斗力却不是一件简单的事情。这要求框架的设计师具备一定的技术底蕴、经验沉淀、格局和前瞻性,而不是眼界只关注于单个模块本身。
例如,我们即使没有开发过框架,但是应该或多或少使用过,知道一个框架至少会包含哪些模块。当我们需要写日志的时候,我们知道这种组件框架必定提供,那么会去框架中寻找并从官网获得使用帮助。当我们需要WebServer、数据库访问、模板引擎等等能力的时候,我们也可以预料得到,这种组件框架必定会有提供,那么也会去框架中寻找并从官网获得使用帮助。
再例如,我们在使用框架中各种模块的时候,虽然各个模块都是低耦合设计,按需引入使用,但是发现她们的配置管理方式都是一致的,都是结构化的配置管理对象,通过相同的配置管理模块,通过固定的配置项到配置对象属性映射规则,通过Get
/Set
开头的方法进行读取和设置(所有组件的参数获取和设置也是Get
/Set
开头的方法),全局的环境变量/启动参数设置也是类同的。这使得开发者能够快速认知到框架行为,做到快速接入、降低学习成本的目的。
再例如,在框架层面有一个非常棒的特性 - 全错误堆栈特性,框架所有组件的error
返回均带有错误堆栈,便于顶层业务在出错时通过错误堆栈快速定位问题。目前Golang
开发语言下仅GoFrame
框架有此能力。
以上只是举的几点简单示例,如果您感兴趣,可以从框架中发现更多有趣的点。
最后,我们可以想一想,为什么我们潜意识中能够认知到框架的行为、框架能够提供极高的便捷性和极低的接入成本、框架模块在"高内聚,低耦合"的设计思想下却整体有着非常高的组织协调性。为什么会造成这样的现象?其实这就是框架采用体系化设计,还是"东拼西凑"。
二、开发规范化
代码层面也是需要有一系列的开发规范,如基本的 代码结构、分层模型、封装设计等,具体请参考:工程开发设计(🔥重点🔥)。统一的框架设计,将会使得所有的业务项目按照统一的代码设计进行编码,形成统一的开发规范。此外,框架的开发工具链也会使得开发规范更容易快速推广和落地实施:开发工具 。
三、组件统一化
这里的统一化有两层概念:
- 多个相同功能组件统一为一个组件。
- 多个不同功能组件统一到框架管理。
另一个痛点就是开发组件的百花齐放:
- 实现相同功能逻辑的模块较多,选择成本增加
- 项目依赖的模块过多,项目整体的稳定性会受到影响
- 项目依赖的模块过多,项目无从下手是否应当升级这些模块版本
- 项目依赖的模块过多,容易出现不同模块依赖同一第三方模块不同版本,引发版本兼容问题
- 各个模块孤立设计,单独看待每个模块可替换性很高,开发体系难以建立,开发规范难以统一
统一的开发框架才能将各个模块"各自为政"的状态收归到"统一管理":
- 框架自顶向下设计,形成体系化、统一化的模块设计,更有利于开发规范化的实施
- 框架核心维护较全面的通用基础模块,降低基础模块选择成本
- 我们只需要维护一个统一的框架版本,而不是数十个模块版本
- 我们只需要了解一个框架的内容变化,而不是数十个模块的内容变化
- 升级的时候只需要升级一个框架版本,而不是数十个模块版本的升级
- 统一的模块化设计可以减少不必要的逻辑实现,提高模块性能及易用性
- 减轻开发人员的心智负担,提高模块可维护性,更容易保证各业务项目的模块版本一致性
四、版本一致性
版本一致性问题主要来源于项目依赖的模块过多、版本过多,造成版本很难以统一维护和升级。开发框架将模块统一化管理后,更容易保证项目模块的版本一致性。但是需要注意的是,这种一致性不是强一致性,只是降低了模块及版本的维护复杂度,但是不一致性的问题依然存在。关于痛点和改进我们在之前的章节也有介绍过,同时也可以参考章节:模块化设计 。这里不再赘述。
行业内也有一些版本强一致性的代码管理方案,例如采用Monorepo
大仓的代码管理方式,却各有利弊,可自行了解,这里不赘述。
五、解决方案沉淀
基于统一的开发框架,更容易形成解决方案沉淀,企业与社区形成良性循环。解决方案的沉淀优先采用工具以及代码形式,而不是文档。
六、避免资源浪费
当每个团队都在试图自己创造轮子时,不仅无法形成统一的开发规范,而且会出现非常多的资源浪费。
这在Golang
语言流行的初期,或者一个初创公司技术体系不完善的初期,现象比较明显。
让项目组把精力更多的投入到业务中,相信这是大多数技术公司的共识。使用统一的开发架构,可以把共性的技术问题提炼出来,并形成通用的解决方案。避免每个项目都独自去解决遇到的各种各样的技术难题,有效的把精力释放出来。
11 Comments
FLY的狐狸
读完goframe文档,胜读一本书啊
郭强
狐狸大佬,一起来书写篇章啊
强仔
狐狸老师,2.0的视频搞起来
cplasfwst
狐狸老师,哭求2.0教程,着实搞不懂!
today
狐狸老师,2.0的视频搞起来呀,我可以接受付费
山辣
请问狐狸老师的1.0视频教程在哪可以获取?
FengY
初学go时,最大乐趣就是去github、google淘开源库,日志用什么,错误处理用什么,HTTP框架用什么等等。后来就累了。
go作为新兴语言,确实没有java中spring框架那种统一的方便,什么都要找,而且要重新学,知识没法复用,不知道学的意义是什么。
所以我想,随着go的慢慢发展,未来肯定会有一款类似spring的框架一统江湖,所谓分久必合,我的感受应该也是大部分go开发者的相同感受,而且现在也能看出这种趋势,无论是go-zero、kratos、jupiter、还是GoFrame,都在往这个方向走。
但综合一圈看下来,还是GoFrame做的最好,无论从文档上,设计上,还是使用上,个人都感觉比较顺手,但感觉GoFrame还是有一块拼图没完成,就是RPC框架缺失。
本来还想说GoFrame在云原生方面也没有提及,比如注册中心、限流之类的,但感觉现在趋势是ServiceMesh,把这些东西都做到sidecar里了,这样来说,GoFrame不提及这块,专注做模块也是不错的选择。
dengao
赞同,我也是看了一圈,心智负担太重,感觉还是goframe好用。期待 Katyusha。哈哈
yusael
发表一下个人意见,
shiqinfeng
这么简洁的语法,居然说丑?是因为语法糖太少吗?运行效率也比java虚机好吧
shiqinfeng
看到框架中已经集成了grpcx, 可以自动注册服务到etcd,实现轻量版的微服务