不同规模时的开发模式

最近有点空闲，想着把这么多年经历的公司在不同规模的时候，开发项目的模式（或者说节奏）总结一下；想着也是经历了技术团队从几个人到几百人，也经历了大厂的模式；回过头来看看，其实每种方式都有着自己的道理；毕竟：存在即合理

没有最好的模式，只有最符合你当前环境的模式

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.点击部署

可能有人会有疑问，只是一个简单的页面，做了一件简单的事情；为什么拖这么久；现在回想起来，个人想法可能原因有几点

• 1. 人少，规模小，大家没有意识到这个问题
• 2. 自动化后，没有人工把关，老板没有安全感（规模很小且追求速度，开发和测试的质量确实堪忧）

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 各类文档，各类数据等等

小结一下

• 基本每一条规则，都是因为造成了生产环境的事故后，被一一总结出来的，逐步应用到各个环节。
• 至于为什么不一开始就参考一些大厂的规范来进行？
  • 答案其实很简单：无法落地实施。
  • 大厂的规范是很完善，但是人家也有着相应的基础设施来提供支持；但是中小公司是很难有的
• 在快速发展的过程中，各种问题层出不穷，有的问题一直存在，但是由于各种原因没有去修复或者升级，历史包袱太重
• 规范从制定出来到大家都能遵守执行，其实是一个很久的时间（不是员工不肯，是无法一蹴而就）

个人建议：

1. 如果各位处于这个阶段，需要能有人(比如CTO)站出来，阶段性的（例如半年一次）还技术债，升级架构；发展的越快，这个必要性越高
2. 规模小的时候，能力突出的员工可以一人撑起一片天；慢慢大了以后，做不到，不是能力问题，各方利益，依赖等等都会是阻碍

2. 大厂模式

随着公司发展几年后，由于疫情和一些原因，我离职了；去了腾讯，看看大厂是啥模式

待写