关于工程师:一名全栈工程师的技术实践之路

全栈开发是指开发人员把握了前端、后端以及数据库等多个畛域的常识和技能，可能独立实现整个我的项目的开发工作。在需要交付过程中，能够负责从我的项目的后期剖析、设计到前期开发、测试、公布等整个过程，可能疾速定位和解决问题，进步开发效率和产品质量。

我认为全栈的推动是环境变动、技术倒退导致的必然结果，全栈带来的益处次要有两方面：

升高沟通老本，晋升交付效率：精细化分工导致的后果是协同老本大大增加，尤其是对于跨多个团队的我的项目，每个开发可能找对接的同学都得找好几个人才能找到，影响整体的需要交付效率。当下，由单人或单团队实现需要的闭环开发，升高协同或者是晋升产品交付效率的最快形式。
从全局视角加深畛域业余度、加强集体竞争力：首先，无论是前端技术、客户端技术还是服务端技术，研发平台、框架、标准都根本定型，学习老本升高；其次，通过学习全栈技术，能够减少技术视角的广度，将来进行开发工作时，不再偏居一隅，能够从整个我的项目的角度登程，设计更正当的架构；最初，将来市场须要的也是全栈型开发同学，在《Stack Overflow 2021 寰球 8W 名开发者调查报告》显示排名前三别离是：全栈工程师（49.7%）、后端工程师（43.7%）、前端工程师（27.4%）。

全栈技能不是无中生有，须要每个开发学习跨栈常识，并且一直实际，能力实现全栈开发、独立交付需要。为此，推广了一套比拟规范的需要落地 SOP，保障需要的交付品质。

分级规范

分级流程

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

前端同学依据需要分级流程实现需要定级
与业余前端协商后指定需要承接同学
承接同学评估工时
工时对焦及优化（业余前端、承接同学）

需要开发 & 公布将以一个全栈需要实际为例进行介绍，详见第 3 章，次要能够分为以下几步：

筹备工作
代码开发
本地调试
公布

全栈推动须要建设在需要交付品质不变、效率晋升的前提下才有意义，保障全栈需要的交付品质次要通过 CR 和上线追踪的形式。

所有全栈研发的代码由业务前端 owner 或师兄强制 CR；
发动 CR 机会，在实现我的项目开发和自测后，全栈同学需及时提交 CR 给师兄和业务前端 owner；
师兄和业务前端 owner 实现代码 review 后，全栈同学依照要求进行代码修复；

线上追踪

统计千行缺陷率、可自测发现率、线上问题数、预警量等指标，纳入全栈交付品质统计；
线上故障由业务前端 owner 和理论开发人独特解决，线上缺点由全栈开发同学修复；

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

先知平台服务于阿里巴巴国内站行业小二，通过寰球趋势洞察、站内供应剖析，输入品类策略，赋能行业小二品类布局。本需要展现站外热搜关键词榜单，不便行业小二疾速洞察站外趋势，Demo 如下：

进行前端开发工作前，须要筹备本地编译环境，依照我的了解，对前端的相干编译工具类比到后端不便大家了解：

在正式开发之前，拉取前端我的项目代码，学习我的项目代码构造，遵循前端开发标准。

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     // 路由配置

每次前端开发都须要新建变更，最初造成一个独立的版本号。在前端页面展现时，通过版本号决定出现的页面版本。

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

筛选栏：展现筛选项、搜寻栏
详情 Tab：展现多个 Tab，本次开发的关键词榜单就是其中一个 Tab 页面

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

确定了组件构造，再联合我的项目目录构造，不难确定代码开发的地位：

筛选栏革新：革新 query-header-container 文件夹下的组件代码
详情 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 榜单主页款式

原款式

指标款式

解决思路

能够看到，整个款式简直是没有变动的，区别是须要将“比照周期”暗藏，同时将“抉择行业”提到第一行，相对来说比拟容易批改。只须要判断以后抉择的 Tab 页，而后确定渲染逻辑即可。React 中反对依据条件判断是否渲染某组件，只须要在条件表达式后跟 &&, 则示意若条件表达式成立，则渲染组件，否则不渲染。例如：

class QueryContainer extends Component {render(){
    return (
      {currentTab === 'keyword' && (<div> 关键词榜单筛选栏 </div>)}
      {currentTab !== 'keyword' && (<div> 品类榜单筛选栏 </div>)}
    );
  }
}

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

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

同时，React 也反对三目运算符，例如：

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

通过以上逻辑判断，能够实现对筛选栏的革新，依据不同 Tab 展现不同款式。

指标款式

解决思路

整个列表能够被分为两局部：表头和表数据。为了放弃整个站外商品库榜单的格调对立，这里没有抉择间接应用 Table 组件，而是抉择了定制化水平更高的 Grid 栅格布局，通过将页面分为 10 列多行，最初通过 css 调整表格的款式。Grid 栅格布局反对依照行、列构建页面，将页面分为多个网格，十分不便自定义页面格调。例如：

class keywordTable extends Component {render(){
    return (
      <Row>
        <Col span="12" className="class1"> 第一列 </Col>
        <Col span="12" className="class2"> 第二列 </Col>
      </Row>
    );
  }
}

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

渲染表头

表头与表数据款式不同，同时内容也是固定的，所以能够独自渲染，我将其抽为独自的渲染函数，局部代码如下：

class keywordTable extends Component {renderTableHeader(){
    return (
      <Row className="product-table-header">
        <Col className="header-keyword" span="3">
          关键词
        </Col>
        <Col className="header-keyword-category" span="4">
          所属类目
        </Col>
        <Col className={this.getTitleClassName('avgSold')} span="2">
          品均月销量 ($)
          <Icon
            type="descending"
            size="xs"
            onClick={() => this.onSortChange('avgSold', 'avg_sold')}
          />
        </Col>
        ...
      <Row>
    );
  }
}

在每个网格内，能够任意的渲染组件，比方上例中我就在其中一个网格内嵌入了降落图标的 Icon。React 还反对动静的拼接每个组件的 className，上例中，我封装了一个动静获取 className 的办法，用于实现点击排序后，排序字段高亮的款式。

渲染表数据

表数据的每一行对前端来说是雷同的，只须要遍历表数据，一行一行的进行渲染即可，局部代码如下：

class KeywordTable extends Component {renderTableKeyword(){
    return (
      <div className="keyword-table-container">
        {dataList.map((item = {}, index) => {
          return (<Row key={index} className="keyword-table-item">
              <Col className="item" span="3">
                {item.keyword}
              </Col>
              <Col className="item" span="4">
                {item.cateName}
              </Col>
              ...
            </Row>
          );
        })}
      </div>
    );
  }
}

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

组装渲染函数

下面将数据列表拆分为表头和表数据进行渲染，最初须要将两者放到组件的渲染函数中才会失效，代码如下：

class KeywordTable extends Component {render(){
    return (
      <React.Fragment>
        {this.renderTableHeader()}
        {this.renderTableKeyword()}
      </React.Fragment>
    );
  }
}

上文提到筛选栏的款式须要在原有根底上进行革新，依据用户抉择的不同详情 Tab 确定展现的款式，但在渲染筛选栏组件时，还无奈确定以后用户抉择的是哪个 Tab；同时，筛选栏抉择不同的筛选项并通过申请后端接口返回不同数据后，须要让数据列表展现不同的数据，但拉取数据和展现数据是在两个组件中实现的。这些中央就波及到组件之间的通信，须要让筛选栏与下方的详情 Tab 交互，从而执行不同的渲染逻辑。类比后端，每个组件相当于一个类，组件渲染进去的页面成果即是一个对象，想要实现两个对象之间的通信，能够有两种思路：

两个对象之间自身存在蕴含关系，例如对象 A 蕴含对象 B，这时候 A 能够轻松的获取 B 的属性；
两个对象之间存在一个媒介，通过媒介进行交互，例如对象 C 同时蕴含对象 A 和对象 B，这时候 A 和 B 能够通过 C 轻松交互；

这里我应用了第 2 种思路，也就是父组件。内容页面同时蕴含了筛选栏和详情 Tab 两个组件，这就是人造的媒介。父组件中保护两个子组件须要通信的变量作为属性，子组件通过读写父组件中的属性来实现交互。

子组件读父组件属性

state

Java 中的类属性能够间接定义在类中；与之类似，每个前端的组件也能够保护本人的属性，区别在于，前端组件的属性须要放在 state 中。例如：

class AAA extends Component {
  state = {
    currentTab: 'keyword',
    dataList: []}
  render(){const {currentTab} = this.state
    <QueryContainer currentTab={currentTab}/>
  }
}

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
      <QueryContainer 
          currentTab={currentTab}
          setDataList={this.setDataList}/>
  }
}

class QueryContainer extends Component {onSearchBtnClick(){
    // 结构新的 dataList
    newDataList = ...;
    this.props.setDataList(newDataList);
  }
}

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

确定待代理的 URL
应用 LightProxy 配置前端代码 Host 绑定，例如：

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

本例中的绑定将所有蕴含门路 http://dev.g.alicdn.com/pagani-assets/alita-xianzhi 的 http 拜访申请代理到前端代码编译失去的文件夹中，实现本地调试的成果

应用 LightProxy 配置后端预发接口代理，例如：

127.0.0.1 future.alibaba-inc.com

本例中将所有拜访域名的申请路由到指定 ip 的机器上，实现本地拜访预发接口的成果

启动 LightProxy 代理，如下图，如果 LightProxy 左侧配置项上有绿点，且菜单栏中的零碎代理项前有小勾，则示意代理失效中

关上浏览器，关上“开发者工具”，Chrome 浏览器快捷键 F12
拜访代理的 URL
搜寻被代理的前端申请中的任意字符串，比方 xianzhi
查看拜访的 ip 地址，如果是 127.0.0.1 则阐明代理失效

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

开发同学将前端代码打包并推送到 CDN 上；
用户拜访服务器，服务器确定以后应用的版本号；
服务器向 CDN 申请某版本号的前端代码包；
CDN 找到对应的前端代码并返回给服务器；
服务器向用户响应页面文件。

景象

起因

npm 实质上是一个相似于 Maven 的包管理器，如上报错是因为我的项目依赖版本呈现抵触，导致 npm 不晓得应用哪个版本，这时候能够间接强制装置，应用 package.json 中配置的版本即可

解决办法

应用命令行 npm install –force 替换 tnpm install

景象拜访页面时本地批改代码不失效起因可能导致该景象的起因较多，比方：

LigthProxy 代理配置谬误
LigthProxy 代理失败或未启动
页面缓存导致代理不失效

解决办法

查看本地我的项目启动是否胜利
拜访门路是否正确
LightProxy 开启是否胜利
LightProxy 中配置的本地资源门路是否正确
清空缓存，重启 LightProxy，多刷新几次试试

造就全局视角，加深畛域业余度

在传统的需要迭代交付中，开发总是站在某一个视角看整个业务，对业务整体框架不足认知。通过全栈交付，为开发同学提供更高的维度、更全局的视角，这样能够更好地了解业务模型、业务流程和不同模块之间的关系，从而更好地把握业务的实质和指标，晋升畛域了解，加深畛域业余度，更快成为某个畛域的专家。

升高沟通老本，晋升交付效率

沟通老本在迭代需要交付过程中曾经成为不可漠视的一部分，尤其是跨团队的需要对接，接口沟通、联调将会破费大量工夫。通过全栈进行需要交付，省去了多人之间的沟通老本，让开发专一在需要上，而不是与内部沟通上。全栈交付也能够在肯定水平上防止返工问题，比方在定义接口的时候，有些细节没思考分明，导致出入参的构造存在一些问题。如果是非全栈需要，须要从新跟前端同学对接，针对接口是否正当的探讨可能就会破费 1 个小时，而后前段再从新开发页面，节约大量工夫。而如果是全栈需要，我能够间接批改接口，不须要跟前端同学再去交换一遍，前端页面也能够在后端接口确认之后再开始搭建，不存在返工问题。

拓展技术广度，加强集体竞争力

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

作者 | 慕钦

点击立刻收费试用云产品开启云上实际之旅！

原文链接

本文为阿里云原创内容，未经容许不得转载

关于工程师:一名全栈工程师的技术实践之路

一、前言

1.1 什么是全栈

1.2 为什么做全栈

二、全栈需要开发 SOP

2.1 需要分级

2.2 需要评估

2.3 需要开发 & 公布

2.4 需要品质保障

2.5 需要复盘

三、全栈需要实际

3.1 背景

3.2 筹备工作

3.2.1 环境筹备

3.2.2 相熟代码

3.2.3 新建变更

3.3 代码开发

3.3.1 模块划分

3.3.2 筛选栏开发

3.3.3 详情 Tab 开发

3.3.4 组件通信开发

3.4 本地调试

3.4.1 代理配置

3.4.2 如何判断代理是否失效

3.5 公布

3.6 常见问题

3.6.1 npm 装置依赖失败

3.6.2 代理不失效

四、全栈开发心得