前言
面试官: 从拿到一个需求到上线,你会做什么?
我: 拿到就开始画页面,画完页面就拿着后端的接口扔进去。然后疯狂改bug。改的差不多了,就上线。
面试官: 回去等消息吧!
说的很真实,也是很多小公司的现状。可面试官就是不满意。
没办法,回去再润色润色吧。
思考
尽管是润色,也还是要从实际出发。既然是开发,那目的就是为了保证需求正常上线,减少开发成本,缩短开发周期。(缩着缩着就被开了!)
按照上学时做阅读理解时的方法,开发前,开发中,开发后。
开发前
俗话说得好,不懂需求的开发,不是一个好开发。bingo!那就得理解需求。
如何理解需求呢?
1. 制定需求技术方案
技术方案,从需求角度大致可以分为 迭代
与 新项目
两种。区别在于 新项目 需要考虑的方面更多一点,比如基础工具搭建,技术选型,git_flow规则等。
由于本文主要目的在于记清楚开发流程,所以不会深入其他方案的细节。后面会单独写文章讲解。
参考这两个模板用于参考
这个环节结束之后,大致的需求工时及方案已经成型,但是还是存在一些不明确的需求,以及必要的与后端同学对齐的细节。后面就需要解决这些问题。
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
-
基于主分支拉取feature-xxx分支
-
基于feature-xxx分支拉取功能分支
本地分支push远程分支时,创建pr 用于团队其他成员codereview
-
功能开发完成后,合并到feature-xxx分支
-
根据测试提供的基础case进行自测,自测通过后,提交测试。
-
基于feature分支拉取uat分支或合并到已有的uat分支并提测。
-
测试过程中的bugfix依旧继续具体功能分支修复并执行上面3 4步。
-
测试完成后,基于feature分支创建release分支用于发布上线。
-
上线后,依旧存在bug风险,需要保留release分支,当出现bug后,基于release分支拉取hotfix分支,并重走3以后的步骤
-
线上版本大概一周后趋于稳定,这是就需要基于feature分支创建Tag 分支并删除所有临时分支
-
在后续使用过程中,如果发现bug就继续main分支拉取hotfix分支,并重走3 以后的步骤,如果当前的uat分支与线上版本有冲突,需要拉取染色分支单独发布。
开发后
开发完成后。并不是一次迭代结束了。我们还需要做复盘
复盘bug
针对开发中的bug,上线后的bug进行复盘,这个复盘不是甩锅,应该针对具体技术问题自己解决方案进行优先级定义,再根据优先级制定后续的优化方案,并在后续的开发中优化掉。
复盘合作
复盘与其他职位小伙伴的合作问题,必要时应拉会对齐gap,避免误会。并制定合理的解决方案。
复盘业务
组织业务串讲,打破团队内部业务壁垒,避免一人只做一块业务,方便团队动态调整人力。
一点点细节
- 一定要多质疑,友善的质疑是对工作伙伴得负责,也是对自己的负责,不仅要质疑需求的合理性,也要质疑代码的可维护性。深入业务,做好技术,才能做好业务。
- 一定要多讨论,开发者的工作绝不仅仅是coding,有效而深入的沟通一定会为你带来方便,提高效率。
- 一定要尊重成果,尊重自己的成果,也要尊重别人的成果。一切信任都是建立在尊重的基础上的。
- 一定不要忽视流程和规范的重要性,条条大路通罗马,可是一个团队一定是沿着一条路一个标准走,才可以更好。
- 拒绝重复造轮子,过分的轮子,一定会导致严重的内耗。也一定包含着对他人成果的藐视。
总结一下
- 多质疑
- 多讨论
- 尊重一切
- 重视流程与规范
- 拒绝重复造轮子
这是我这4年多的开发经历,带给我的一些经验,绝对不完善,但是也希望与大家一起讨论,喜欢的话点个关注点个赞,有问题欢迎评论区开怼!
原文链接:https://juejin.cn/post/7355088718371684362