最近有点空闲,想着把这么多年经历的公司在不同规模的时候,开发项目的模式(或者说节奏)总结一下;想着也是经历了技术团队从几个人到几百人,也经历了大厂的模式;回过头来看看,其实每种方式都有着自己的道理;毕竟:存在即合理
文章目录
没有最好的模式,只有最符合你当前环境的模式
1. 10人规模
16年到20年,在一家跨境旅游的公司,感觉自己还是幸运的;公司发展的特别快,我去的时候,技术团队前后端加起来,一个圆桌就坐下了,每次来新人,都会出去吃一顿;后来公司快速成长,光技术团队就有3百人左右的规模;能经历一次从小到中等规模的发展,也是一段不错的经历。
随着规模的迅速扩展,开发模式也发生了很大的改变
人少:怎么快怎么来
人少的时候,CTO(创始人之一)常说:怎么快怎么来,慢了,公司就GG了。
当时开发一个新功能,前后端一合计,需要什么接口,后端就开始写代码(我是后端开发)
- 先确定接口吗?
可能会有人说,这还用问吗,肯定要确定接口,然后各自开发啊。
但实际没那么美好,规模小的时候,往往需求都是不确定的,可能早上跟你说,我们新增的一种商品,客人购买的时候,需要多填个信息(比如使用日期);然后当你开发了一半,又说,还得再加一个。接口都是边写边改,很难碰到一个最后版本跟当时定义的接口是一样的去上线的 - 技术文档如何管理?
没有文档,
不要惊讶,就是没有文档,功能少,人少,大家都靠口口相传,实在不确定的就去看一下代码;接口文档是代码自动生成的(比如 go swagger),但经常代码改了,但是文档没更新,导致无法使用。【规模大了以后,文档绝对的重要】 - 技术选型如何抉择?
看老大的,因为老大技术强,出问题了能Hold住,所以当需要引进新的技术点的时候,需要老大点头;比如之前数据库一直使用MySQL,哪天新的业务需要用Neo4J(真实场景),需要老大拍板
因为当时一个需求,传统关系数据库不适合,搜出来说neo4j很适合,大家都觉得适合,但是还是不敢下决心,毕竟不知道会踩什么坑。
-
架构设计?
我记得,当时我们做跨境旅游,最初的时候分3大块:商品、订单、库存。- 各个模块有1到两三个服务(我们是微服务架构)。
- 数据库用的MySQL,
- 缓存用Redis
- 开发语言Golang (还有Java,据说刚开始大半年是外包的技术,用Java写的,后来才有自己的技术人员,也开始把外包的代码逐步替代)
- 服务器:aws 云服务器
- 部署:人工执行部署脚本
可以发现都是最常用的,没什么新意,但是重在:稳定、好用
-
感受
当时刚毕业一年,感觉过的很充实,因为每天都会有很多需求提出来,然后马上做,马上测试,马上上线;天天赶工。由于人少,如果发现什么问题自己不知道的,基本靠Google【其实不是什么难题,只是当时自己太菜】;虽然很忙,每段时间回顾,还发现自己多了点技能,每次赶出来的东西,都能快速上线,被用户使用,还有反馈,感觉还挺好。
随着公司的快速发展,慢慢的,我们不止是做产品需求了,我们发现技术债慢慢的多了,到了必须还一些的时候了
2. 百人规模
随着业务发发展,后台服务的规模也快速的膨胀着;接下来出现了很多事情
2.1.服务发版方式改变
2.1.1 老版本
- 老的发版方式:代码测试通过 -> push到master 分支 -> 人工告诉老大 -> 老大登录机器,执行脚本(拉取最新代码->编译->运行)
-
如果是新服务,还得先看看http服务用的是哪个端口,如果已经占用,则替换成未用的,然后还需要手动配置NGINX
-
可能你会认为很原始,效率很低;但是我们这种模式持续了小一年。
其实规模小的时候,这种方式是有优点的
- 发版权限只有一个人有,且发版前,能保证老大是知道的
- 发版前后,老大一般会去简单检查一下,保证是服务是OK的
- 如果开发人员不知道服务的依赖,在最后发版的时候,老大是一层人工检测
但是再继续下去,老大估计要吐血了。
2.1.2 自动部署系统初版应运而生
功能很简单:
- 1.登录
- 2.选择服务 (如果是新服务,人工先配置)
- 3.选择分支
- 4.点击部署
可能有人会有疑问,只是一个简单的页面,做了一件简单的事情;为什么拖这么久;现在回想起来,个人想法可能原因有几点
-
- 人少,规模小,大家没有意识到这个问题
-
- 自动化后,没有人工把关,老板没有安全感(规模很小且追求速度,开发和测试的质量确实堪忧)
2.2.各开发规范陆续制定
在人少的时候,其实是没什么规范的;但是规模大了以后,不得不出规范,因为人工不可控了。
2.2.1 微服务
- 创建一个新服务,需要有合适的理由,以及对服务的定位。
- 新创建的服务,目录树风格统一等
- 抽象出公共功能库
- 引入第三方库需要组内评估
- ……
2.2.2 数据库的使用
- Mysql 建表的规范,必须字段,关键索引的创建
- 代码里面 SQL 的Code review
早期,为了快,很多逻辑用SQL可以快速的完成,就直接使用了,导致了很多很复杂的SQL的存在
- 定期慢查询log 回顾
让一下慢查询暴露出来,及时得到处理
- 数据库权限的控制 【很重要】
这里说的不是操作人的,是服务的;早期,大家都可以直接连数据库,进行增删改查,特别是:查询,即使商品的逻辑,可能直接查询库存的表来达成目的;后来变成了谁写的数据,谁可以查,其他人需要查的,统一通过api查询
2.2.3 服务使用的配置文件方式
以前服务启动时候的配置文件都是一个静态的文件,部署的时候带着一起的;
后来配置文件融合到部署系统里了,再后来,同一服务不同实例不同配置、配置热更新等也都支持了,
2.2.4 测试验收
人多了以后,测试也开始有测试用例的评审,验收标准的制定等等
2.2.5 各类文档,各类数据等等
小结一下
- 基本每一条规则,都是因为造成了生产环境的事故后,被一一总结出来的,逐步应用到各个环节。
- 至于为什么不一开始就参考一些大厂的规范来进行?
- 答案其实很简单:无法落地实施。
- 大厂的规范是很完善,但是人家也有着相应的基础设施来提供支持;但是中小公司是很难有的
- 在快速发展的过程中,各种问题层出不穷,有的问题一直存在,但是由于各种原因没有去修复或者升级,历史包袱太重
- 规范从制定出来到大家都能遵守执行,其实是一个很久的时间(不是员工不肯,是无法一蹴而就)
个人建议:
- 如果各位处于这个阶段,需要能有人(比如CTO)站出来,阶段性的(例如半年一次)还技术债,升级架构;发展的越快,这个必要性越高
- 规模小的时候,能力突出的员工可以一人撑起一片天;慢慢大了以后,做不到,不是能力问题,各方利益,依赖等等都会是阻碍
2. 大厂模式
随着公司发展几年后,由于疫情和一些原因,我离职了;去了腾讯,看看大厂是啥模式
待写