面试官：从拿到一个需求到上线，你会做什么？

前言

面试官: 从拿到一个需求到上线，你会做什么？

我: 拿到就开始画页面，画完页面就拿着后端的接口扔进去。然后疯狂改bug。改的差不多了，就上线。

面试官: 回去等消息吧！

说的很真实，也是很多小公司的现状。可面试官就是不满意。

没办法，回去再润色润色吧。

思考

尽管是润色，也还是要从实际出发。既然是开发，那目的就是为了保证需求正常上线，减少开发成本，缩短开发周期。（缩着缩着就被开了！）

按照上学时做阅读理解时的方法，开发前，开发中，开发后。

开发前

俗话说得好，不懂需求的开发，不是一个好开发。bingo！那就得理解需求。

如何理解需求呢？

1. 制定需求技术方案

技术方案，从需求角度大致可以分为 迭代 与 新项目两种。区别在于 新项目 需要考虑的方面更多一点，比如基础工具搭建，技术选型，git_flow规则等。

由于本文主要目的在于记清楚开发流程，所以不会深入其他方案的细节。后面会单独写文章讲解。

参考这两个模板用于参考

这个环节结束之后，大致的需求工时及方案已经成型，但是还是存在一些不明确的需求，以及必要的与后端同学对齐的细节。后面就需要解决这些问题。

2. 对齐需求疑问点

这个环节就进入很重要的沟通阶段了。一个合格的开发，应该学会质疑，带着解决方案的质疑。这样有助于自己理解需求及业务。

3. 对齐接口及数据接口。

很多同学在开发工程中，会把对齐接口这一步放在最后，或者和接口联调混淆。其实对齐接口是开发前就该做的。要做哪些事呢？

1. 根据技术方案，确认需要后端提供哪些接口。这个过程要有取舍，那些操作适合前端处理，那些后端处理更合理。切记，要笑，别挨打。
2. 确认后端接口的数据结构，拒绝一个接口做多个事。根据技术方案中的最方便的数据结构，如果后端有自己的考虑而拒绝。前端应该对相关模块或组件进行封装。
3. 确认接口文档时间。尽量提前返回。

开发中

做完上述工作构，就要进入开发阶段了。是不是觉得，这个阶段不就是画页面，调接口吗？还能有啥呢？

然也然也。这个阶段是最复杂的。关键的东西也很多。接着看吧！

1. 新项目需要初始化项目。

这一步涉及到技术选型，代码检查，基础工具等。不过多赘述，各种各样的脚手架，模板，选择适合自己即可。

2. git 分支管理。我们着重从git入手流程。

下面目录提供git分支分类。

scss

代码解读

复制代码

主分支 main / master 长期分支，存放最新已上线版本代码。 版本分支 Tag分支 长期分支 用于保留历史版本的代码，当release分支上线稳定后。基于feature分支到main分支，并基于main 创建Tag分支 开发分支 feature-xxx(‘xxx’为版本) 临时分支,用于存放当前开发版本的总代码分支， feature-xxx_something 临时分支，基于 feature-xxx 创建的新分支，用于保存某一具体功能。 uat. 临时分支，用于基于一个或多个feature-xxx分支合并创建的测试环境分支，用于测试。 release-xxx(‘xxx’为版本或日期) 临时分支，用于基于main 分支以及一个或多个feature-xxx分支合并创建的预发环境和生产环境，用于发布线上。 bugfix分支 hotfix--xxx(‘xxx’为bug描述) 临时分支，基于线上的release-xxx分支，用于修复上线后的bug，修改后基于当前fix分支新建uat分支并提测，而后合并release分支重发线上。线上验收完成，删除分支

通过上面的分支分类大概可以梳理开发中的git-flow

1. 基于主分支拉取feature-xxx分支

2. 基于feature-xxx分支拉取功能分支

   本地分支push远程分支时，创建pr 用于团队其他成员codereview

3. 功能开发完成后，合并到feature-xxx分支

4. 根据测试提供的基础case进行自测，自测通过后，提交测试。

5. 基于feature分支拉取uat分支或合并到已有的uat分支并提测。

6. 测试过程中的bugfix依旧继续具体功能分支修复并执行上面3 4步。

7. 测试完成后，基于feature分支创建release分支用于发布上线。

8. 上线后，依旧存在bug风险，需要保留release分支，当出现bug后，基于release分支拉取hotfix分支，并重走3以后的步骤

9. 线上版本大概一周后趋于稳定，这是就需要基于feature分支创建Tag 分支并删除所有临时分支

10. 在后续使用过程中，如果发现bug就继续main分支拉取hotfix分支，并重走3 以后的步骤，如果当前的uat分支与线上版本有冲突，需要拉取染色分支单独发布。

开发后

开发完成后。并不是一次迭代结束了。我们还需要做复盘

复盘bug

针对开发中的bug，上线后的bug进行复盘，这个复盘不是甩锅，应该针对具体技术问题自己解决方案进行优先级定义，再根据优先级制定后续的优化方案，并在后续的开发中优化掉。

复盘合作

复盘与其他职位小伙伴的合作问题，必要时应拉会对齐gap，避免误会。并制定合理的解决方案。

复盘业务

组织业务串讲，打破团队内部业务壁垒，避免一人只做一块业务，方便团队动态调整人力。

一点点细节

• 一定要多质疑，友善的质疑是对工作伙伴得负责，也是对自己的负责，不仅要质疑需求的合理性，也要质疑代码的可维护性。深入业务，做好技术，才能做好业务。
• 一定要多讨论，开发者的工作绝不仅仅是coding，有效而深入的沟通一定会为你带来方便，提高效率。
• 一定要尊重成果，尊重自己的成果，也要尊重别人的成果。一切信任都是建立在尊重的基础上的。
• 一定不要忽视流程和规范的重要性，条条大路通罗马，可是一个团队一定是沿着一条路一个标准走，才可以更好。
• 拒绝重复造轮子，过分的轮子，一定会导致严重的内耗。也一定包含着对他人成果的藐视。

总结一下

1. 多质疑
2. 多讨论
3. 尊重一切
4. 重视流程与规范
5. 拒绝重复造轮子

这是我这4年多的开发经历，带给我的一些经验，绝对不完善，但是也希望与大家一起讨论，喜欢的话点个关注点个赞，有问题欢迎评论区开怼！

原文链接：https://juejin.cn/post/7355088718371684362