起因

多人运动非常可怕, 需要一个相对规范的流程来控制项目开发.

流程仅供参考, 结合实际项目进行增/删, 反对低效率的教条主义.

流程

1.需求文档

看需求文档，我们要根据需求文档来确定我们究竟要做什么。

一些同学可能感觉 为什么还要用一个需求文档呢，你就告诉我做啥我就做啥不就完事了。

其实需求文档一方面是倒逼产品经理去系统性的思考这个需求究竟有哪些功能，用来满足哪些用户的需求。

另一方面，是保证我们在研发的时候，研发出来的功能是满足需求文档里所描述的。

如果是口头对接的话，很有可能就是你做出来的东西，产品经理看完感觉：这和我说的需求不一样啊！！这和我想的不一样啊！！

这样就是两个人相互甩锅，那这究竟是谁的锅呢。都没有一个证据，对吧。

所以说，有一个需求文档很重要。

而且每个阶段的需求文档相当于是把这个项目的整个迭代过程都记录下来了。

这样也方便后面的人，了解这个项目是如何迭代的。

2.这个需求包含了哪些功能

产品经理在需求文档里描述一个功能，那么我们在实现的时候，可能要改很多模块，或者说我们要增加一些模块。

就是我们从代码的角度上来讲，可能要增添很多功能才能满足 用户看起来好像微不足道的小功能。

例如点击登录，点击下单，后台都有很多模块协同运行的。

我们要把产品经理角度上的这个功能，拆解为我们代码角度上的具体应该开发的那些功能。

3.确定有哪些难点

这里可能有同学疑惑了，我确定这东西干嘛呢。

给大家举一个例子，给你一个需求文档。

你说你一周的时间就能把它开发完，那为什么是一周呢，为什么不是两天，为什么不是两周呢。

其实 和上面的领导汇报你的工作的时候 都要把自己的工作进行量化。

那么这个功能有哪些难点，我们要克服这个难点，所需要花费的时间，都要有一个大体的量化。

这样才能量化我们自己的工作，领导其实不知道你的工作是简单 还是困难, 领导只在意最终结果，所以你要展现给领导你的工作是有难度的是有挑战的。

而且这些也是我们年底用来晋升或者评职称的素材。

如果这些东西你自己都不在乎的话，谁还会帮你在乎呢。

而且确定了自己的工作难点，把这些难点都记录下来，对以后跳槽也很有帮助。

面试官最喜欢问的问题，就是：你做的项目中有哪些难点？以及你是如何克服的。

所以这一步对自己个人成长来说也是很有重要的。 对于项目组来说也是记录下来，每一个迭代版本有哪些难点，这些难点团队是如何克服的。

这也是项目组往上一级去邀功的资料。

4.画架构图

一般来说，大厂项目的架构都是比较复杂的，特别是后端架构。

如果添加一个模块连个文档都没有，连个图也没有，上来就添加的话，后面的人是很难维护的。

而且每个模块和每一个模块之间的依赖关系，如果没有画出一个架构图的话，直接看代码很容易直接就看懵了。

为什么你可以快速开发一个新的模块，也是因为之前团队有人把这个架构图画清楚了，你只需要看一眼这个架构图，就知道你的模块应该添加在哪里。

那么你去添加模块的时候，也应该把这个架构图相应的位置 完善一下。

同时呢，在画架构图的过程中，也增添了自己对整个系统架构的掌握程度。

这个图也会让你确定，你的模块在整个项目中扮演一个什么样的角色。

5.定协议

后台模块之间进行通讯需要协议，后台和前端通讯也需要协议。

所以只要有交互，就要确定协议的数据格式。

定协议要考虑到兼容，要考虑易于维护。

6.设计/调用数据结构和算法

其实设计数据结构更多一些，因为我们要选择使用什么容器，什么格式来处理我们的数据。

至于算法的话，就很少我们亲自设计了。

什么快排，二叉树，动态规划，最短路啥的，在实际开发中，都不需要我们自己去写，直接调包！

面试造火箭，工作拧螺丝 就体现在这里。

为什么会这样呢？ 一个很简单的例子，互联网研发讲究其实就是要快，例如一个功能2天就要开发完，如果算法都要自己去写的话，等都写完了，花都谢了。

7.预估一下容量

特别是后端开发，要估计出 我们自己模块大体需要多大磁盘，多大内存，多大带宽，多少核CPU。

这也是没有做过研发工作的同学经常忽略的，因为大家好像默认 磁盘、内存、带宽、cpu是无穷的。

其实我们在设计一个模块的时候，这些都要评估的，不能模块一上线，把机器直接打爆了，例如 直接把带宽打满了，不仅影响自己的模块功能，还影响了机器上其他模块的运行。

8.考虑部署

要考虑如果一台机器挂了（可能是硬件原因），那么我们的模块还能不能正常提供服务。

这就是考虑模块的容灾性，一般都是采用分布式，服务部署在三台机器上，一台如果挂了，还有其他两台提供服务。

还有就是要弹性可伸缩，即我们的模块可不可以直接 部署多台机器来提高承载能力。

如果用户量突然上来了，或者流量突然上来了，可以通过快速部署多台机器来抗住流量。而不是模块只能在单机上跑，多部署几台就发生各种问题。

这才能说明是有足够强的风险意识的。

9.设计评审

前八的阶段其实都是设计阶段，那么你的设计需要让组里的同学一起来评审一下，看看有没有什么问题。

大家主要也是看看你的模块 会不会给其他模块或者整个系统带来什么问题 以及 设计的是否合理。

10.写代码

终于到写代码的阶段了，其实到这时候，是最容易的。

写代码就是体力活了，不是脑力活了。

11.自测

写完代码，我们需要自测，自己的功能会不会有什么问题。

这里可能需要自己造一造数据，跑一跑 看看和预想的是不是一样的。

12.联调

自己的模块可能会涉及到其他模块之间的一个交互，或者和前端的一个交互。

所以需要其他同学配合一起来测试。

这里就有很多沟通工作了，因为其他同学可能手头有自己的活，那么就要协调一个时间来一起测试。

这一步也是很费时间的，其费时关键是要等，要等其他同学有空和你联调，而且往往不是联调一次就能解决问题的。

所以 在评估开发时间的时候 也要考虑到联调的时间。

这也是大厂研发效率低的地方，但上百人开发的项目，这种沟通上消耗也是在所难免的。

13.交给专人测试

自己的代码，自己测 一般都测不出什么问题，需要交给测试同学来给你测一测。

这里如果测试同学测出问题，你就要判断确实有问题还是 测试方式不对，如果有问题就要修改，在提给测试，反反复复这么几轮，直到测试同学测试没问题了。

这个过程也是累心的。

14.code review

代码合入主干之前，需要 项目组的同学一起来评审一下你的代码。

之前是评审设计，看设计上有没有什么缺失，这次是大家来看看你代码写的怎么样。

例如合入主干会不会有什么问题，代码兼容性做的好不好，接口设计的好不好，甚至字段，函数，变量名，命名合不合理。

都要经过大家的评审，如果有问题就还是要改。

如果没有问题一般 大家会给+2（就是通过的意思），这样就可以合入主干了。

15.合入主干

合入主干为什么会单独列出来呢。

其实合入主干是很重要的，经常是自己的代码没问题，但合入主干之后就有问题了。

一般就是合入主干的时候有冲突，例如你从主干拉出一个分支，另一个同学从主干拉出一个分支，而且两个分支修改了同一个模块，如果另一个同学提前合入主干，你在合入主干的时候就会有代码冲突。

在解决代码冲突的时候 就会修改别人的代码，这个过程很容易产生新的bug。

一般合入主干之后，测试同学还要重新跑一个全量测试，才能放心发布。

16.发布

最后一步就是发布了。

发布其实就是把主干的代码更新到线上的服务器上。

一些还没有工作的同学，可能不太理解究竟什么是发布。

用大白话来讲，就是把 本地的代码或者某台机器的代码，编译成可执行文件，然后更新到 线上的服务器（一个独立的集群，专门处理线上的流量）并运行起来。

上线是最重要的一步了，也很容易出问题，因为一个大型项目，其上线的过程都非常复杂（要更新上百台机器的集群），而且要考虑线上新版和旧版本的兼容问题。

这也是为什么大厂项目都选择深夜上线，因为深夜在线用户最少，如果出问题，影响的用户会比较少，可以快速修复。

所以大家经常看到 某大厂程序员深夜上线发布版本之类的。

Copyright

@2021-2022 代码随想录 版权所有
原文传送门