本文比较系统的介绍了什么是全栈以及全栈开发的具体步骤和实践，最后分享了作者做全栈的心得体会。

一、前言

1.1 什么是全栈

全栈开发是指开发人员掌握了前端、后端以及数据库等多个领域的知识和技能，能够独立完成整个项目的开发工作。在需求交付过程中，可以负责从项目的前期分析、设计到后期开发、测试、发布等整个过程，能够快速定位和解决问题，提高开发效率和产品质量。

1.2 为什么做全栈

我认为全栈的推进是环境变化、技术发展导致的必然结果，全栈带来的好处主要有两方面：

  • 降低沟通成本，提升交付效率：精细化分工导致的结果是协同成本大大增加，尤其是对于跨多个团队的项目，每个开发可能找对接的同学都得找好几个人才能找到，影响整体的需求交付效率。当下，由单人或单团队完成需求的闭环开发，降低协同或许是提升产品交付效率的最快方式。

  • 从全局视角加深领域专业度、增强个人竞争力：首先，无论是前端技术、客户端技术还是服务端技术，研发平台、框架、规范都基本定型，学习成本降低；其次，通过学习全栈技术，可以增加技术视角的广度，未来进行开发工作时，不再偏居一隅，可以从整个项目的角度出发，设计更合理的架构；最后，未来市场需要的也是全栈型开发同学，在《Stack Overflow 2021 全球8W名开发者调查报告》显示排名前三分别是：全栈工程师（49.7%）、后端工程师（43.7%）、前端工程师（27.4%）。

二、全栈需求开发SOP

全栈技能不是无中生有，需要每个开发学习跨栈知识，并且不断实践，才能实现全栈开发、独立交付需求。为此，推行了一套比较标准的需求落地SOP，保证需求的交付质量。

2.1 需求分级

分级标准
将所有的跨栈需求划分为A、B、C、D四个等级，具体定义如下：
等级
描述
A
  • 涉及的页面、模块有较高的体验要求（如性能、还原度），对前端专业知识有深度要求
  • 涉及的页面、模块有特殊的前端工程体系，与主流方案不同且上手成本很高
B
  • 需求涉及富交互的页面、模块，对页面状态管理和组件通信等要求较高
  • 开发的页面、模块与其他业务系统存在集成/被集成关系（跨业务关联）
  • 相关需求涉及对当前工程配置的改动，可能影响整个应用
  • 其他未归为A类的前台买家场景需求
C
  • 相关功能需沉淀可复用组件以复用至同业务中其他场景
  • 涉及第三方工具、组件、模块引入的需求，兼容性不明确
D
  • 简单的增删改查，针对数据操作的用户界面
  • 可通过简单复用完成开发的页面、模块
  • 可通过生产力工具快速搭建的页面、模块
  • 技术平台及运营配置平台的相关功能开发
  • 其他未归为A、B、C类的需求
分级流程

2.2 需求评估

对全栈需求的评估主要分为以下四步：

  • 前端同学根据需求分级流程完成需求定级

  • 与专业前端协商后指定需求承接同学

  • 承接同学评估工时

  • 工时对焦及优化（专业前端、承接同学）

2.3 需求开发 & 发布

需求开发 & 发布将以一个全栈需求实践为例进行介绍，详见第3章，主要可以分为以下几步：
  • 准备工作
  • 代码开发
  • 本地调试

  • 发布

2.4 需求质量保障

全栈推进需要建立在需求交付质量不变、效率提升的前提下才有意义，保障全栈需求的交付质量主要通过CR和上线追踪的方式。
CR

  • 所有全栈研发的代码由业务前端owner或师兄强制CR；

  • 发起CR时机，在完成项目开发和自测后，全栈同学需及时提交CR给师兄和业务前端owner；

  • 师兄和业务前端owner完成代码review后，全栈同学按照要求进行代码修复；

线上追踪
  • 统计千行缺陷率、可自测发现率、线上问题数、预警量等指标，纳入全栈交付质量统计；
  • 线上故障由业务前端owner和实际开发人共同处理，线上缺陷由全栈开发同学修复；

2.5 需求复盘

全栈之路不可能一帆风顺，中间总是会有各种磕磕绊绊，失败是在所难免的，失败不是成功之母，好的复盘才是，所以全栈路上，迭代复盘必不可少。商家技术团队每两周会对全栈迭代进行一次复盘，总结Highlight、Lowlight，以及后续的Action。

三、全栈需求实践

3.1 背景

先知平台服务于阿里巴巴国际站行业小二，通过全球趋势洞察、站内供给分析，输出品类策略，赋能行业小二品类规划。本需求展示站外热搜关键词榜单，方便行业小二快速洞察站外趋势，Demo如下：

3.2 准备工作

3.2.1 环境准备

进行前端开发工作前，需要准备本地编译环境，按照我的理解，对前端的相关编译工具类比到后端方便大家理解：
工具名称
类型
类比后端工具
下载链接
Node
运行环境
JVM
https://nodejs.org/en/download
npm
包管理器
Maven
https://nodejs.org/zh-cn/download
VSCode
编译器
IntelliJ Idea
https://code.visualstudio.com/download
LightProxy
代理
–

3.2.2 熟悉代码

在正式开发之前，拉取前端项目代码，学习项目代码结构，遵循前端开发规范。
alita-xianzhi    |--- hook                // 钩子脚本    |--- .eslintignore      // eslint格式校验忽略文件    |--- .eslintrc.js        // esliint格式配置文件    |--- package.json        // 依赖包版本（类似pom.xml）    |--- src                // 源代码          |-- common             // 定义项目常量，比如目录，常用文字说明等          |-- components         // 公共组件目录          |-- entry              // 跳转页          |-- pages             // 页面代码，文件名与 URL 路径相对应          |-- service           // 服务，接口请求地址          |-- utils             // 公用方法          |-- index.jsx          // 主页          |-- index.scss        // 主页样式css          |-- tab-config.js     // 路由配置

3.2.3 新建变更

每次前端开发都需要新建变更，最后形成一个独立的版本号。在前端页面展示时，通过版本号决定呈现的页面版本。

3.3 代码开发

3.3.1 模块划分

在正式开发代码之前，先分析下页面，理清开发思路，划分待开发的组件，确定最终的代码结构。
页面上方和左侧的菜单栏为通用组件，本次开发不需要修改。除此之外的页面可以划分为两大块：

  1. 筛选栏：展示筛选项、搜索栏

  2. 详情Tab：展示多个Tab，本次开发的关键词榜单就是其中一个Tab页面

由此，确定最终的组件结构，如下图：

确定了组件结构，再结合项目目录结构，不难确定代码开发的位置：

  1. 筛选栏改造：改造query-header-container文件夹下的组件代码

  2. 详情Tab：在aaa文件夹下新增keyword-table文件夹，然后在里面写代码

src                 |-- pages                |-- outside-opportunity-discovery               |-- components    // 站外机会发现组件                       |-- query-header-container  // 筛选框组件                             |-- index.jsx            // 筛选框组件主页                             |-- index.scss            // 筛选框组件主页样式                       |-- aaa                  // aaa榜单                             |-- keyword-table        // aaa关键词榜单列表                                     |-- index.jsx            // aaa关键词榜单主页                                     |-- index.scss            // aaa关键词榜单主页样式                             |-- index.jsx            // aaa榜单主页                             |-- index.scss            // aaa榜单主页样式

3.3.2 筛选栏开发

原样式
目标样式
解决思路
可以看到，整个样式几乎是没有变化的，区别是需要将“对比周期”隐藏，同时将“选择行业”提到第一行，相对来说比较容易修改。只需要判断当前选择的Tab页，然后确定渲染逻辑即可。React中支持根据条件判断是否渲染某组件，只需要在条件表达式后跟&&,则表示若条件表达式成立，则渲染组件，否则不渲染。例如：
class QueryContainer extends Component {  render(){    return (      {currentTab === 'keyword' && (        
关键词榜单筛选栏      )}      {currentTab !== 'keyword' && (        
品类榜单筛选栏      )}    );  }}

上例中，相当于有两个if条件语句，伪代码如下：

if(currentTab == 'keyword'){    展示关键词榜单筛选栏}if(currentTab != 'keyword'){    展示品类榜单筛选栏}

同时，React也支持三目运算符，例如：

class QueryContainer extends Component {  render(){    return (      {currentTab === 'keyword' ? (        
关键词榜单筛选栏      ) : (        
品类榜单筛选栏      )}    );  }}

通过以上逻辑判断，可以实现对筛选栏的改造，根据不同Tab展示不同样式。

3.3.3 详情Tab开发

目标样式
解决思路
整个列表可以被分为两部分：表头和表数据。为了保持整个站外商品库榜单的风格统一，这里没有选择直接使用Table组件，而是选择了定制化程度更高的Grid栅格布局，通过将页面分为10列多行，最后通过css调整表格的样式。Grid栅格布局支持按照行、列构建页面，将页面分为多个网格，非常方便自定义页面风格。例如：
class keywordTable extends Component {  render(){    return (              第一列        第二列          );  }}

Grid栅格布局将每一个行划分为24个小列，只需要指定span，即可按比例设置列的宽度。className可以轻松的定制每个网格的样式。上例中，使用Grid栅格布局渲染了一行，并将其平分为两列。

渲染表头
表头与表数据样式不同，同时内容也是固定的，所以可以单独渲染，我将其抽为单独的渲染函数，部分代码如下：
class keywordTable extends Component {  renderTableHeader(){    return (                        关键词                          所属类目                          品均月销量($)           this.onSortChange('avgSold', 'avg_sold')}          />                ...          );  }}

在每个网格内，可以任意的渲染组件，比如上例中我就在其中一个网格内嵌入了下降图标的Icon。React还支持动态的拼接每个组件的className，上例中，我封装了一个动态获取className的方法，用于实现点击排序后，排序字段高亮的样式。

渲染表数据
表数据的每一行对前端来说是相同的，只需要遍历表数据，一行一行的进行渲染即可，部分代码如下：
class KeywordTable extends Component {  renderTableKeyword(){    return (      
        {dataList.map((item = {}, index) => {          return (                                          {item.keyword}                                            {item.cateName}                            ...                      );        })}          );  }}

上例中，首先遍历数据列表中的每一个对象，在遍历时，需要给对象设置默认值，避免对象为null导致页面渲染异常，然后取对象中的各属性值并渲染到网格中。

组装渲染函数
上面将数据列表拆分为表头和表数据进行渲染，最后需要将两者放到组件的渲染函数中才会生效，代码如下：
class KeywordTable extends Component {  render(){    return (              {this.renderTableHeader()}        {this.renderTableKeyword()}          );  }}

3.3.4 组件通信开发

上文提到筛选栏的样式需要在原有基础上进行改造，根据用户选择的不同详情Tab确定展示的样式，但在渲染筛选栏组件时，还无法确定当前用户选择的是哪个Tab；同时，筛选栏选择不同的筛选项并通过请求后端接口返回不同数据后，需要让数据列表展示不同的数据，但拉取数据和展示数据是在两个组件中完成的。这些地方就涉及到组件之间的通信，需要让筛选栏与下方的详情Tab交互，从而执行不同的渲染逻辑。
类比后端，每个组件相当于一个类，组件渲染出来的页面效果即是一个对象，想要实现两个对象之间的通信，可以有两种思路：

  1. 两个对象之间本身存在包含关系，例如对象A包含对象B，这时候A可以轻松的获取B的属性；

  2. 两个对象之间存在一个媒介，通过媒介进行交互，例如对象C同时包含对象A和对象B，这时候A和B可以通过C轻松交互；

这里我使用了第2种思路，也就是父组件。内容页面同时包含了筛选栏和详情Tab两个组件，这就是天然的媒介。父组件中维护两个子组件需要通信的变量作为属性，子组件通过读写父组件中的属性来完成交互。

子组件读父组件属性
  • state
Java中的类属性可以直接定义在类中；与之相似，每个前端的组件也可以维护自己的属性，区别在于，前端组件的属性需要放在state中。例如：
class AAA extends Component {  state = {    currentTab: 'keyword',    dataList: []  }  render(){    const {currentTab} = this.state      }}
  • props
在Java中，类的初始化使用构造器，解析构造器中的参数实例化对象；与之相似，前端组件在渲染时，可以通过解析传入参数初始化，这个参数统一封装到props中，可以通过this.props访问。例如：
class QueryContainer extends Component {  render() {    const {currentTab} = this.props;  }}
通过以上方法，可以让子组件随时感知到父组件的属性值变化，只要currentTab值改变，React框架会检测到props值改变，从而触发子组件重新渲染，调用render()函数，最终实现根据不同Tab渲染不同筛选栏的效果。
子组件写父组件属性
Java支持将函数作为Function对象进行参数传递，与之相同，React框架也支持将函数作为参数，通过props传递。如果子组件希望写父组件属性，只需要将父组件中写state值的操作封装为函数，然后传递给子组件即可。例如：
class AAA extends Component {  state = {    currentTab: 'keyword',    dataList: []  }  setDataList(newDataList){    this.setState({newDataList});  }  render(){    const {currentTab} = this.state        }}class QueryContainer extends Component {  onSearchBtnClick(){    // 构造新的dataList    newDataList = ...;    this.props.setDataList(newDataList);  }}

3.4 本地调试

3.4.1 代理配置

前端代码在开发完后可以在本地直接启动、并调用服务端的预发接口，从而实现本地调试，步骤如下：

  1. 确定待代理的URL

  2. 使用LightProxy配置前端代码Host绑定，例如：

^dev.g.alicdn.com/pagani-assets/alita-xianzhi/**/** file://Users/zhangpoxi/webStormProject/alita-xianzhi/build/$2

本例中的绑定将所有包含路径dev.g.alicdn.com/pagani-assets/alita-xianzhi的http访问请求代理到前端代码编译得到的文件夹中，实现本地调试的效果

  1. 使用LightProxy配置后端预发接口代理，例如：
127.0.0.1 future.alibaba-inc.com
本例中将所有访问域名的请求路由到指定ip的机器上，实现本地访问预发接口的效果

  1. 启动LightProxy代理，如下图，如果LightProxy左侧配置项上有绿点，且菜单栏中的系统代理项前有小勾，则表示代理生效中

3.4.2 如何判断代理是否生效

  1. 打开浏览器，打开“开发者工具”，Chrome浏览器快捷键F12

  2. 访问代理的URL

  3. 搜索被代理的前端请求中的任意字符串，比如xianzhi

  4. 查看访问的ip地址，如果是127.0.0.1则说明代理生效

3.5 发布

用户看到的页面本质上将就是文件，所以前端代码打包完成后都会推送到CDN，通过版本号确定需要拉取的文件，如图所示主要分为以下几步：

  1. 开发同学将前端代码打包并推送到CDN上；

  2. 用户访问服务器，服务器确定当前使用的版本号；

  3. 服务器向CDN请求某版本号的前端代码包；

  4. CDN找到对应的前端代码并返回给服务器；

  5. 服务器向用户响应页面文件。

3.6 常见问题

3.6.1 npm安装依赖失败

现象
原因
npm本质上是一个类似于Maven的包管理器，如上报错是因为项目依赖版本出现冲突，导致npm不知道使用哪个版本，这时候可以直接强制安装，使用package.json中配置的版本即可
解决办法
使用命令行npm install –force替换tnpm install

3.6.2 代理不生效

现象
访问页面时本地修改代码不生效
原因
可能导致该现象的原因较多，比如：

  • LigthProxy代理配置错误

  • LigthProxy代理失败或未启动

  • 页面缓存导致代理不生效

解决办法

  • 检查本地项目启动是否成功

  • 访问路径是否正确

  • LightProxy开启是否成功

  • LightProxy中配置的本地资源路径是否正确

  • 清空缓存，重启LightProxy，多刷新几次试试

四、全栈开发心得

  • 培养全局视角，加深领域专业度

    • 在传统的需求迭代交付中，开发总是站在某一个视角看整个业务，对业务整体框架缺乏认知。通过全栈交付，为开发同学提供更高的维度、更全局的视角，这样可以更好地理解业务模型、业务流程和不同模块之间的关系，从而更好地把握业务的本质和目标，提升领域理解，加深领域专业度，更快成为某个领域的专家。
  • 降低沟通成本，提升交付效率
    • 沟通成本在迭代需求交付过程中已经成为不可忽视的一部分，尤其是跨团队的需求对接，接口沟通、联调将会花费大量时间。通过全栈进行需求交付，省去了多人之间的沟通成本，让开发专注在需求上，而不是与外部沟通上。全栈交付也可以在一定程度上避免返工问题，比如在定义接口的时候，有些细节没考虑清楚，导致出入参的结构存在一些问题。如果是非全栈需求，需要重新跟前端同学对接，针对接口是否合理的讨论可能就会花费1个小时，然后前段再重新开发页面，浪费大量时间。而如果是全栈需求，我可以直接修改接口，不需要跟前端同学再去交流一遍，前端页面也可以在后端接口确认之后再开始搭建，不存在返工问题。
  • 拓展技术广度，增强个人竞争力

    • 当下，AI能力越来越强，降低了跨栈开发的门槛，人人都可以借助AI能力，进行跨栈开发，我们在深挖专业技能的同时，技术广度也是不可获取的一部分，全栈能力必然是大势所趋。目前先知的全栈实践局限在前端、后端，未来的全栈可以继续向数据开发、算法等方向发展，一人成军，让迭代需求交付没有卡点。未来的技术发展需要拥有全栈能力的人才能够更好地适应，跨界合作将成为趋势。因此，通过拓展技术广度，不仅可以增强个人竞争力，还能够在职场中获得更多的机会和挑战，实现自我价值的最大化。

作者|慕钦

本文来自博客园，作者：古道轻风，转载请注明原文链接：https://www.cnblogs.com/88223100/p/The-Technical-Practice-Path-of-a-Full-Stack-Engineer.html