摸索前端管理2年,这份研发流程帮到我不少

本文分享了一名前端工程师的经验,介绍了如何建立接地气的前端研发流程,包括统一的开发环境镜像、开发流程图、VSCode扩展、Nginx代理配置、依赖管理和Gitlab中的issue驱动开发。作者还提供了《2024年Web前端开发全套学习资料》以帮助前端工程师提升技能。
摘要由CSDN通过智能技术生成

点击上方卡片“前端司南”关注我

您的关注意义重大

原创@前端司南

在现在的公司工作也有2年多了,时间过得真快!2年的时间里,前端从单兵作战发展到现在的10人规模。如果要我说,这个过程里什么最重要?我想应该是一份接地气的研发流程

说到研发流程,大部分人肯定首推某某某大厂的研发流程。诚然,大厂的研发流程的确完善并且细致,然而实际上并不一定适用于其他公司或团队,比如QA、单元测试、自动化测试这些环节,我想很多公司都不会有。所以,盲目地套用别的公司或者团队的研发流程,是可能水土不服的,但是却可以给我们提供一个参考意见,去弥补自身的不足。

研发流程一定不是凭空出现的,它必须紧密贴合实际的项目过程。我很重视这块,在我还是“光杆司令”的时候,我就在筹备着。我当时的想法是,等我这个组进人的时候,我一定不是手把手告诉他做项目的每一步该怎么做,而是用标准化的文档把整个大致过程记录下来,另外也是想要告诉我未来的同事,我这个团队是有思考和沉淀的,值得大家一起成长!

研发流程一定不是完美的,但它一定是与时俱进的。我回顾了一下这份文档,前前后后修改了不下100次。

接下来针对前端研发流程这块分享一下我们的实践,希望给有需要的朋友一点帮助!

整体流程

====

团队整体的一个研发流程大致如下:

这块可能大部分公司都是大同小异,没什么好细说的。实际上,可能每个环节是否执行到位也是需要打个问号的。

前端研发流程

======

系统镜像


为了方便新入职同事快速进入状态,我们制作了统一的前端开发系统镜像,避免了出现电脑装机和各种环境配置出现的问题,产生一些不必要沟通而浪费时间。

最早的时候,还是我出的一个简单的文档,告诉新同事要装什么什么软件这样子,但是发现问题还是挺多,用了镜像后,省心不少。

前端研发流程图


这张图描述了前端日常开发的主要过程,可以花个1到2分钟好好看看。

研发资源


  • 原型设计:axure

  • 视觉设计:蓝湖,iconfont

  • api文档:swagger

  • 敏捷协作:TAPD,研发日常的任务,需求,缺陷等工作都集中在TAPD[1]平台上。

  • 源码仓库:自建Gitlab

  • 团队文档:语雀

处理IconFont图标


在图标管理这块,我们使用的是 iconfont,包括字体图标和矢量图标都有用到,并且封装了对应的组件icon-fonticon-svg,目前主要以使用icon-svg为主,icon-font主要面向部分项目。

在 iconfont 上调整好图标后,需要重新生成链接

  • 对于字体图标组件 icon-font,生成在线的 font class 链接,替换掉项目中 index.html 中的对应链接才会生效。

  • 对于矢量图标组件 icon-svg,生成在线的 symbol 链接,替换掉 icon-svg 组件中引用的 js 链接才会生效。

issue驱动


虽然git log已经提供了记录查询的能力,但是还不够便捷,直观。

我们采用issue驱动开发,所有的代码改动都应该先在gitlab创建issue,包括但不限于需求,缺陷,自测试,优化类改动。

commit是可以自动关联和关闭issue的,这样一来,我打开每一个issue,就知道这个issue关联了哪些代码提交记录,查问题非常直观!另外,这也是众多开源项目常见的协作方式。

对于需求、缺陷类型的开发任务,应在创建issue时附上TPAD相关链接,方便跳转查询。

issue应该保证原子性,一个issue只做一件事。

开发流程


VSCode扩展

首先,安装必要的 VSCode 扩展,结合项目中配置的 Lint/Formatting 能力,达到一个高效开发的状态。

全局依赖

// 保证 yarn 的正常使用

npm install -g yarn

// 用于规范 commit 提交

npm install -g commitizen

npm install -g conventional-changelog-cli

npm/yarn代理

npm 自带的源有时候速度太慢,或者有时候根本下载不了某个包,容易导致 install 失败或停顿,请统一使用 taobao 代理。

npm config set registry https://registry.npm.taobao.org

// 部分项目使用yarn

yarn config set registry https://registry.npm.taobao.org

Nginx代理配置

我们在开发者本地使用 Nginx 作为中间代理,加一层本地 Nginx 代理的目的是:

  • 统一项目访问的服务端口,防止误提交项目配置文件,避免不必要的代码冲突。

  • 便于切换不同环境时,实现秒级切换,不用重启 devServer。后面这里可以优化下,据我观察,ant-design-pro 实现了不重启 devServer 更新 proxy,有空研究下!

  • 如果比较反感,不强制增加本地 Nginx 这一层,可以自行指定后端 gateway 地址,但是注意不要提交 vue.config.js 文件,避免引起冲突!

  1. 下载windows稳定版本Nginx,链接是http://nginx.org/en/download.html[2]

  1. 修改nginx/conf/nginx.conf

一个基本的代理配置如下:

worker_processes 1;

events {

worker_connections 1024;

}

http {

include mime.types;

default_type application/octet-stream;

sendfile on;

keepalive_timeout 65;

#gzip on;

server {

listen 8090;

server_name 127.0.0.1;

location / {

proxy_pass http://xxx.xxx.tech;

proxy_http_version 1.1;

proxy_set_header Upgrade $http_upgrade;

proxy_set_header Connection “upgrade”;

proxy_set_header Host $host;

proxy_set_header X-Real-IP $remote_addr;

proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

}

}

}

nginx 统一监听 127.0.0.1:port,代理请求到后端 gateway。在需要切换环境时只需要修改 proxy_pass 这一项即可。

  1. 前端工程默认配置 proxy 的 target 为 http://127.0.0.1:port,配合Nginx使用时,不要修改此项。

  2. 常见命令

#linux中

#开机启动

systemctl enable nginx

#启动

systemctl start nginx

#重启

nginx -s reload

#windows中

#启动

直接打开nginx.exe

#重启

修改配置文件后重启,可以选择cmd打开根目录,然后nginx.exe -s reload

#其他

如果重启有问题,一般是点击了多次nginx.exe,这时候可能启动了多个nginx,算是个windows版本的bug吧,

可以直接打开任务管理器找到所有nginx进程,然后结束掉。最后直接打开nginx.exe启动。

关于这一环节,我之前还写过一篇「前端必看」这篇Nginx反向代理技巧,助你准时下班陪女神,想要详细了解的朋友可以打开看看。

项目依赖安装

目前有的项目使用npm管理依赖,有的使用的是yarn。进入项目时,观察lock文件,如果项目根目录有yarn.lock,则说明使用yarn;如果项目有package-lock.json,说明使用npm

安装依赖时根据情况执行以下命令:

  • npm

npm install

  • yarn

yarn

需求/缺陷分配

TL负责任务分配,将TPAD上的需求进行分配,指定开发责任人。

TAPD的需求分发到个人后,都要求开发人员拆分出前端子需求(不限于1个),根据自身能力和需求复杂度评估出开发时间规模,根据自己的排期填写预估起始时间结束时间,项目经理会追这个事情,责任到个人。如果有逾期风险,提前向 TL 或者自己的导师反馈原因,不要拖到最后一天才暴露问题。

按道理,开发时间规模应该是大家做需求评审时定下来的,但是考虑到团队的一个实际情况,这块权限是下放到开发者自行评估,但是 TL 需要起到一个监督的作用。这里大家可以结合实际情况考量。

创建issue

原则上由开发者自行创建,创建需求和 bug 类 issue 时,应附上 tapd 链接,方便查询关联事项!issue 也是分支命名的一个依据。下面我会接着说。

有些时候,TL 或者项目 Owner 会安排一些非 TAPD 管理的组内任务,会直接以 issue 形式指给开发人员,开发人员接到 issue 后,不必再重复创建 issue,只要基于已创建的 issue 创建本地分支开发就行。

分支权限控制

在我们团队中,约定了三个重要分支,分别是:

  • develop:开发分支

  • release:测试分支

  • master:生产分支

这三个分支被设置为 Protected Branches,通常都关联了对应环境的 CI/CD 配置。在权限控制上一般设置为:Maintainer 拥有 Merge 权限,所有人都没有 push 权限

实际操作时,一个基本的 Merge 方向是:

根据实际情况,也可以引入预发布分支之类的分支。

如果对分支权限不做控制,大家可以随意 push,就意味着潜在的灾难随时可能发生。所以这一点是非常值得关注的!

创建分支

我之前也试过分支语义化命名,但是也发现了要用有限的单词描绘出复杂的含义永远是个伪命题。我们可能会在做一个新功能时,会把相关分支命名为feature/xxx,而后面有优化类需求时,又会新建一个feature/xxx-optimization之类的分支。然而,往往一个功能会有一次又一次的优化、变更或 bug,采取这样的命名策略永远会让自己直面灵魂拷问!

并且在追溯问题时,这种分支命名方式往往让人心力交瘁!

那么如何命名能解决这样的问题呢?我采用了下面这种策略!

issue本身有一个编号,或者叫ID,这种唯一标识让我们命名分支变得简单。假定一个issue的编号是1,那么我们在本地创建分支时,只需要将分支命名为issue/1即可,根据这个编号,我就能查到这个分支处理的是哪个issue,而打开 Gitlab 的issue界面,我就能知道这个issue与什么需求或缺陷有关,而且也能直观看到与这个issue关联的代码 commit 记录。这不仅给开发者带来了方便,也让管理者变得更轻松!

好,下面说实际操作。以开发新特性为例:

  • 本地切换到develop分支,拉取最新develop分支代码

git checkout develop

git pull

  • 基于develop分支创建新的特性分支,用于开发新特性,目前统一命名为issue/xxx,其中xxx是你在gitlab上创建的issue号,如下所示:

git checkout -b issue/1

也就是说,issue/1分支用于解决gitlab上的issue 1提到的问题。

有的项目比较简单,或者还在初期阶段,这种情况下,不会设置 develop 分支,而是基于 master 分支快速开发。如果是这种情况,在上面的操作中,可以直接把 master 理解为 develop,依葫芦画瓢即可。

提交代码

特性/缺陷分支应该保证原子性,一个分支只解决一个问题(指的是一个issue提及的问题),否则原则上不允许合入其他分支。这对敏捷迭代有关键意义!

开发完毕后,应提交到远程仓库同名分支。

git add .

git cz // 进行cz交互式命名行提交

git push origin HEAD // 提交到远程仓库同名分支

提交部分代码

如果一次commit希望提交部分文件(而不是全部修改的文件),不要用 git add .,可以结合 GUI 进行选择(比如VSCode自带的Git面板),进入staged状态的文件,就是你希望提交的。

➕ 是进入 staged,➖ 是移出 staged,Staged Changes 就是你希望在这次 commit 的内容。

提交部分代码时,注意保管好自己未提交的代码,未入库就有丢失的可能,这一点要明确!

git cz流程

git czcommitizen提供的能力,这块我之前简单写过一段介绍,具体见规范commit message[3]。使用git cz的主要目的就是规范代码提交。

  1. 选择提交的类型,feat代表需求,fix代表修复缺陷,docs代表文档类变动,style是代码风格层面的(不是指样式…),refactor指的是代码重构,perf则是优化相关的(包括性能/体验等),test是单元测试之类的,build是构建工具相关的,ci是持续集成相关的,chore的解释各异,按commitizen的解释就是非srctest的其他改动,revert代表代码回退…

  2. 请准确选择改动类型!

  1. 影响范围

【按情况填写即可,如果不是过于抠细节,大部分时候可以不填】

What is the scope of this change (e.g. component or file name): (press enter to skip)

  1. 改动描述

【必填】本次代码改动的描述信息,可摘取issue的标题,或者是tapd需求或缺陷的标题,也可以自行总结。

Write a short, imperative tense description of the change (max 94 chars):

登录功能开发

  1. 详细描述

【按情况填写,如果不是过于抠细节,大部分时候可以不填】提供详细描述

Provide a longer description of the change: (press enter to skip)

  1. 是否有重大变更?

【一般是回车或者输入N跳过】一般来说,只有架构层面的变更才会填入y

Are there any breaking changes? (y/N)

  1. 是否影响issue?

【一般来说,一次commit都应该有与之关联的issue,输入y,用来关闭issue,这个是很常见的】

Does this change affect any open issues? (y/N)

【一般可以跳过】如果关联的issue已经关闭,可以针对本次commit 做一个信息补充。

If issues are closed, the commit requires a body. Please enter a longer description of the commit itself:

(-)

  1. 关闭issue?

? Add issue references (e.g. “fix #123”, “re #123”.):

假设要关闭 issue#1,则输入:

fix #1

如果要关闭多个 issue,则输入:

fix #1 #2 #3

  1. 提交至远程同名分支

git push origin HEAD // 提交到远程仓库同名分支

commit 检查

配合 husky 和 git hook 来实现 commit 检查。

  1. 防止提交不符合规范的代码。

  2. 防止commit message不规范。

这里需要借助以下依赖:

  • husky

  • commitlint

  • commitizen

  • conventional-changelog-cli

  • lint-staged

自我介绍一下,小编13年上海交大毕业,曾经在小公司待过,也去过华为、OPPO等大厂,18年进入阿里一直到现在。

深知大多数前端工程师,想要提升技能,往往是自己摸索成长或者是报班学习,但对于培训机构动则几千的学费,着实压力不小。自己不成体系的自学效果低效又漫长,而且极易碰到天花板技术停滞不前!

因此收集整理了一份《2024年Web前端开发全套学习资料》,初衷也很简单,就是希望能够帮助到想自学提升又不知道该从何学起的朋友,同时减轻大家的负担。

img

既有适合小白学习的零基础资料,也有适合3年以上经验的小伙伴深入学习提升的进阶课程,基本涵盖了95%以上前端开发知识点,真正体系化!

由于文件比较大,这里只是将部分目录截图出来,每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频,并且会持续更新!

如果你觉得这些内容对你有帮助,可以扫码获取!!(备注:前端)

最后

给大家分享一些关于HTML的面试题,有需要的朋友可以戳这里获取,先到先得哦。


  • commitlint

  • commitizen

  • conventional-changelog-cli

  • lint-staged

自我介绍一下,小编13年上海交大毕业,曾经在小公司待过,也去过华为、OPPO等大厂,18年进入阿里一直到现在。

深知大多数前端工程师,想要提升技能,往往是自己摸索成长或者是报班学习,但对于培训机构动则几千的学费,着实压力不小。自己不成体系的自学效果低效又漫长,而且极易碰到天花板技术停滞不前!

因此收集整理了一份《2024年Web前端开发全套学习资料》,初衷也很简单,就是希望能够帮助到想自学提升又不知道该从何学起的朋友,同时减轻大家的负担。

[外链图片转存中…(img-RtVBSt9O-1712762990791)]

[外链图片转存中…(img-gNEji3c6-1712762990792)]

既有适合小白学习的零基础资料,也有适合3年以上经验的小伙伴深入学习提升的进阶课程,基本涵盖了95%以上前端开发知识点,真正体系化!

[外链图片转存中…(img-da4SEZpJ-1712762990793)]

由于文件比较大,这里只是将部分目录截图出来,每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频,并且会持续更新!

如果你觉得这些内容对你有帮助,可以扫码获取!!(备注:前端)

最后

给大家分享一些关于HTML的面试题,有需要的朋友可以戳这里获取,先到先得哦。

[外链图片转存中…(img-n2Te7PQb-1712762990793)]
[外链图片转存中…(img-wjgsWWwK-1712762990793)]

  • 24
    点赞
  • 25
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值