一、几个开发中经常会遇到的问题

以下几个问题是我们在实际开发中经常会遇到的场景，下面用几个简单的示例代码来还原一下。

1.setState是同步还是异步的，为什么有的时候不能立即拿到更新结果而有的时候可以?

1.1 钩子函数和React合成事件中的 setState

现在有两个组件

1
2
3
4
5
6
7
8
9
10
11

componentDidMount() {
  console.log('parent componentDidMount');
}
render(){
  return (
    <div>
      <SetState1></SetState1>
      <SetState2></SetState2>
    </div>
  )
}

组件内部放入同样的代码，并在 Setstate1中的 componentDidMount中放入一段同步延时代码，打印延时时间：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

componentWillUpdate(){
  console.log('componentWillUpdate')
}
componentDidUpdate(){
  console.log('componentDidUpdate')
}
componentDidMount(){
  console.log('SetState调用setState')
  this.setState({
    index: this.state.index + 1
  })
  console.log('state', this.state.index);

  console.log('SetState调用setState');
  this.setState({
    index: this.state.index + 1
  })
  console.log('state), this.state.index');
}

下面是执行结果：

说明：

• 1.调用 setState不会立即更新
• 2.所有组件使用的是同一套更新机制，当所有组件 didmount后，父组件 didmount，然后执行更新
• 3.更新时会把每个组件的更新合并，每个组件只会触发一次更新的生命周期。

最早的时候页面是服务端渲染的，也就是 PHP、JSP 那些技术，服务端通过模版引擎填充数据，返回生成的 html，交给浏览器渲染。那时候表单会同步提交，服务端返回结果页面的 html。

后来浏览器有了 ajax 技术，可以异步的请求，服务端返回 xml 或者 json。ajax 最早是基于 xml 的，这也是它名字的由来。因为 xml 多了很多没必要的标签，内容比较多，所以后来 json 流行开来。

网页和服务端的数据交互变成了异步的，可以服务端返回 json 数据，浏览器里拼接 html，之后渲染（浏览器里面生成 dom 就等同于渲染）。页面基本没啥刷新的必要了，于是后来就逐渐演变出了单页应用 SPA（single page application）。

早期开发页面的时候就是基于浏览器的 dom api 操作 dom 来做渲染和交互，但是 dom api 比较啰嗦，而且当时浏览器的兼容性问题也比较麻烦，不同浏览器有不同的写法。为了简化 dom 操作和更方便的兼容各种浏览器，出现了 jquery 并且迅速流行开来，那个时代 jquery 是如日中天的。

我一直习惯把网页分为物理层和逻辑层，dom 就算是物理层，jquery 是操作 dom 的一系列工具函数，也是工作在物理层。

网页做的事情基本就是拿到数据渲染 dom，并且数据改变之后更新 dom，这个流程是通用的，后来逐渐出现了 mvvm 框架，来自动把数据的变更映射到 dom，不再需要手动操作 dom。也就是 vue、react 等现代的前端框架。我把这一层叫做逻辑层。

前端框架除了提供了数据驱动视图变化的功能以外，还支持了 dom 的逻辑划分，可以把一部分 dom 封装成组件，组件和组件之间相互组合，构成整个界面。物理层依然是 dom，只是实现了数据到 dom 的自动映射之后，我们只需要在逻辑层写组件就可以了。

现在前端入门也不会再学物理层的操作 dom 的 jquery 了，而是直接从 vue、react 这种逻辑层的前端框架开始。

https://nodejs.org/download/release/v12.22.4/node-v12.22.4-linux-x64.tar.xz
wget https://nodejs.org/dist/v6.9.5/node-v6.9.5-linux-x64.tar.xz

tar xvf node-v12.22.4-linux-x64.tar.xz
ln -sf /opt/node/node-v12.22.4-linux-x64/bin/node /usr/local/bin/node
ln -sf /opt/node/node-v12.22.4-linux-x64/bin/npm /usr/local/bin/npm

https://www.jianshu.com/p/5f671aca2b5a

前端部署方案

关于部署的总结

静态资源组织部分

1. 为了最大程度利用缓存，将页面(HTML)设置为协商缓存，将 JavaScript、CSS 等设置为永久强缓存。
2. 为了解决强缓存更新问题，将文件摘要（hash）作为资源路径(URL)构成的一部分。
3. 为了解决覆盖式发布引发的问题，采用 name-hash 而非 query-hash 的组织方式，具体需要配置 webpack 的 output.filename 为 contenthash 方式。
4. 为了解决 Nginx 目录存储过大 + 结合 CDN 提升访问速度，采用了 Nginx 反向代理+ 将静态资源上传到 CDN。
5. 为了上传 CDN，我们需要按环境动态构造 publicPath + 按环境构造 CDN 上传目录并上传。
6. 为了动态构造 publicPath 并且随构建过程插入到 HTML 中，采用 Webpack-HTML-Plugin 等插件，将编译好的带 hash + publicPath 的静态资源插入到 HTML 中。
7. 为了保证上传 CDN 的安全，我们需要一种机制管控上传 CDN 秘钥，而非简单的将秘钥写到代码 / Dockerfile 等明文文件中。

自动化部署部分

为了提升部署效率，100% 避免因部署出错，需要设计 & 搭建自动化部署平台，以 Docker 等保证环境的一致性，以 Jenkins 等保证构建流程的串联。使用es-build等提升构建效率。

前端部署 & 静态资源加工

关于前端部署，能总结出下面几个原则/要求：

1. 构建发布后，不应该被覆盖。
2. 构建发布后，静态资源应当永久保存在服务器/CDN 上，即只可读。
3. 静态资源组织上，每个版本应该按文件夹存储，做到资源收敛。这样假如真要删除时，可按版本删除。（如某个版本代码泄密）

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

// webpack.config.js
const CDN_HOST = process.env.CDN_HOST;// CDN 域名
const CDN_PATH = process.env.CDN_PATH''; // CDN 路径
const ENV = process.env.ENV; // 当前的环境等等
const VERSION = process.env.VERSION; // 当前发布的版本

const getPublicPath = () => {
    // Some code here
    return `${CDN_HOST}/${CDN_PATH}/${ENV}/${VERSION}/`;// 依据 ENV 等动态构造 publicPath
}

module.exports = {
    output: {
        filename: 'bundle.[name][contenthash].js',
        publicPath: getPublicPath(),
    },
    plugins: [
        new HtmlWebpackPlugin()
    ]
}

故 publicPath 应增加 version 字段

4. 发布过程应该自动化，开发人员不应该直接接触服务器。
5. 版本切换时，也应当不接触服务器。
6. 版本切换能秒级生效。（如 v0.2 切换 v0.3，立即生效）。
7. 线上需要能同时生效多个版本，满足 AB 测试、灰度、PRE 环境等小流量需求。

上述需求都相对复杂多变，为了应对复杂的线上需求，可以对静态资源做深度加工，如通过服务端直出 HTML、通过配置中心实现按用户 PRE 等等。

前端发布服务

面对复杂的商业化需求，方便多前端业务实现版本管理、灰度、PRE、AB 测试等小流量功能，我们设计了一个中间服务 PageConfig Web & PageServer，与 Nginx 和各种后端相结合，达到配置即时生效的能力。

灵魂拷问的部分答案

Q: 前端代码从 tsx/jsx 到部署上线被用户访问，中间大致会经历哪些过程？
A: 经历本地开发、远程构建打包部署、安全检查、上传CDN、Nginx做流量转发、对静态资源做若干加工处理等过程。
Q：可能大部分同学都知道强缓存/协商缓存，那前端各种产物（HTML、JS、CSS、IMAGES 等）应该用什么缓存策略？以及为什么？

– 若使用协商缓存，但静态资源却不频繁更新，如何避免协商过程的请求浪费？
– 若使用强缓存，那静态资源如何更新？

A：HTML使用协商缓存，静态资源使用强缓存，使用name-hash（非覆盖式发布）解决静态资源更新问题。
Q：配套的，前端静态资源应该如何组织？
A：搭配 Webpack 的Webpack_HTML-Plugin & 配置 output publicPath等。
Q：配套的，自动化构建 & 部署过程如何与 CDN 结合？
A：自动化构建打包后，将产物传输到对应环境 URL 的CDN上。
Q：如何避免前端上线，影响未刷新页面的用户？
A：使用name-hash方式组织静态资源，先上线静态资源，再上线HTML。
Q：刚上线的版本发现有阻塞性 bug，如何做到秒级回滚，而非再次部署等 20 分钟甚至更久？
A：HTML文件使用非覆盖方式存储在CDN上，搭建前端发布服务，对 HTML 按版本等做缓存加工处理。当需要回滚时，更改发布服务HTMl指向即可。
Q: CDN 域名突然挂了，如何实现秒级 CDN 降级修补而非再次全部业务重新部署一次？
A1: 将静态资源传输到多个 CDN 上，并开发一个加载Script的SDK集成到HTML中。当发现CDN资源加载失败时，逐步降级CDN域名。
A2：在前端发布服务中，增加HTML文本处理环节，如增加CDN域名替换，发生异常时，在发布服务中一键设置即可。
Q：如何实现一个预发环境，除了前端资源外都是线上环境，将变量控制前端环境内？
A：对静态资源做加工，对HTML入口做小流量。
Q：部署环节如何方便配套做 AB 测试等？
A：参见前端发布服务
Q：如何实现一套前端代码，发布成多套环境产物？
A：使用环境变量，将当前环境、CDN、CDN_HOST、Version等注入环境变量中，构建时消费 & 将产物上传不同的CDN即可。

其他

如果想深入学习前端部署，下面是一些学习建议。

1. 学习负载均衡（要求：了解）。
   学习和了解负载均衡的原理、都有哪些配置玩法。如参考大型网站架构系列：负载均衡详解
2. 深入学习 HTTP（要求：熟练掌握）
   如掌握常见的状态码、常见的 Header 及其深度应用、强缓存/协商缓存、HTTP2 的新增功能等等。尤其HTTP 1.1 和 HTTP 2.0。
   推荐书籍：
   图解HTTP
   HTTP 权威指南
3. 深入学习前端工程化 （要求：精通）
   – 了解前端工程化可以做什么，如 前端工程化：体系设计与实践
   – 掌握前端工程师的常见实践原理 & 实操
   – 深度学习 Webpack Webpack 官方文档
4. 学习各种对前端静态资源加工的各种方案（要求：掌握）
5. 深度学习浏览器原理 （要求：精通）
   一些资料：从浏览器多进程到JS单线程，JS运行机制最全面的一次梳理

linux文件目录

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

/       - 根
/bin    - 用户二进制文件
/sbin   - 系统二进制文件
/etc    - 配置文件，比如nginx配置文件
/dev    - 设备文件
/proc   - 进程信息
/var    - 变量文件
/tmp    - 临时文件
/usr    - 用户程序
/home   - HOME目录，所有用户用home目录来存储他们的个人档案。
/boot   - 引导加载程序文件
/lib    - 系统库
/opt    - 可选的附加应用程序
/mnt    - 挂载目录
/media  - 可移动媒体设备
/srv    - 服务数据

linux搭建环境

• linux安及配置装nginx
• linux安装git
• CentOs安装node

软件工程师最基本的能力就是算法+coding，经常刷题可以让自己保持手感，我已经坚持3年打卡leetcode，一天未拉下，每天解决一道新题

当然如果你只会刷题，你的竞争力就最多只是做一个合格的额螺丝钉。越高级的软件工程师需要在一个垂直领域有所擅长，比如系统设计。有了 Domain of Expertise，才能更好的升值。

软件工程师需要有一些能拿得出手的作品，可以是之前公司所贡献或领导的产品，也可以是业余弄的 side project，比如可以是开源，或者是一些挣钱的项目。

下载nginx

http://nginx.org/en/download.html

下载稳定版本，以nginx/Windows-1.12.2为例，直接下载 nginx-1.12.2.zip
下载后解压，解压后如下

nginx命令

Windows下Nginx的启动、停止等命令, 可以进入到nginx的安装根目录，执行nginx.exe -h

1
2
3
4
5
6
7
8
9
10
11
12
13
14

注意不要直接双击nginx.exe，这样会导致修改配置后重启、停止nginx无效，需要手动关闭任务管理器内的所有nginx进程
在nginx.exe目录，打开命令行工具，用命令 启动/关闭/重启nginx 
start nginx : 启动nginx
nginx -s reload  ：修改配置后重新加载生效
nginx -s reopen  ：重新打开日志文件
nginx -t -c /path/to/nginx.conf 测试nginx配置文件是否正确
关闭nginx：
nginx -s stop  :快速停止nginx
nginx -s quit  ：完整有序的停止nginx
如果遇到报错：
bash: nginx: command not found
有可能是你再linux命令行环境下运行了windows命令，
如果你之前是允许 nginx -s reload报错， 试下 ./nginx.exe -s reload
或者 用windows系统自带命令行工具运行

一、前言

现在最流行的版本管理工具非git莫属，而良好的代码规范有助于项目的维护，为了防止一些不规范的代码 commit并push到远端,我们可以在git命令执行前用一些钩子来检测并阻止。现在大前端主要有两种git钩子插件：husky（jquery与next.js都在用），pre-commit(antd在用)。
下面我将现介绍一个git钩子，再介绍下husky与pre-commit的用法

二、git钩子

用过git的小伙伴们都知道git有很多命令commit、push、rebase等等。那这些命令主要是在执行.git文件夹中的东西，那么git 钩子目录就是在.git文件夹的hooks下，如下所示：

1
2

cd .git/hooks
ls -l

上图为各个钩子的案例脚本，可以把sample去掉，直接编写shell脚本来执行。
而前端的小伙伴们则可以用插件husky与pre-commit，来使钩子生效。
注意： 一般.git为隐藏文件，可以把项目拖入IDE中查看,.git文件里的内容一般不允许手动更改的。

闲话不多说，直接上代码

设计方案，拿来吧你

今天要跟大家聊聊开发流程中不起眼的环节——设计方案。你们可能没听过，也可能只是简单得走过过场，别划走，这非常重要！

更完善、更规范、更高效的开发流程：产品需求设计 => 需求粗评 => 做设计方案 => 粗估时 => 需求细评 => 排期 => 开发 => 提测、修bug => code review => 上线

平常工作中，比较少接触的可能就是1和code review了，这两者分别是干什么的？

• 设计方案：在拿到需求后，写一个文档，来描述自己对于该需求的实现思路、模块划分等相关考虑的点，可供今后自己或他人查阅。
• Code review：代码提交合并前给mentor或leader检查一下你的代码，让别人作为旁观者来看你的代码，集思广益，完善代码，发现未考虑到的边界问题。