2019年中技术梳理

算上实习，工作三年有余了，公司项目中采用的技术方案换了又换，算上平时自己学习的东西和做的小项目，接触过的各种技术比较杂乱。

由于项目一般都工期紧张，总是忙于学习各种技术如何使用，如何更好地使用，但是在相关的理论知识、实现原理上，可能就是看看书，看看文档，明白个大概就不再深入的学习了。

好好梳理一下三年间使用过的各种技术，同时也是对自己掌握的能力的一个汇总，然后沉下心来补一补基础的理论知识，及各种实现原理，避免沦为业务仔。

很多细节知识点就不一一列出了，主要针对一些提到比较多的主流关键词。

一、前端

前端方面的各种知识点应接不暇，学了三年，依然还有好多没有掌握的东西，路漫漫其修远兮。

Angular1

16 年主要使用的技术栈，Ng1 + TypeScript + Redux，做了几个项目，不过目前已经不是主流的技术了，就不再赘述了，还在使用的小伙伴赶紧拥抱 ng2+ 吧。

React

17 年开始调研，并慢慢全面转向 React 技术栈，从 React + Redux 到 React + Mobx 到 React + Rxjs 到 React + Redux + Redux-Observable + Rxjs。

经过大量项目的实践与总结，团队使用的 React 技术栈目前稳定在 React + Redux + Redux-Observable + Rxjs，同时在使用过 Ng2 + NgRx 后，参考 ng2+ 的模块划分优化了代码结构，按模块拆分了 Redux 的 Store。

Angular2+

目前团队内比较倾向的框架，官方的 cli 比较强大，简单好用，框架本身就提供了大量常用的功能，非常适合制定统一的团队开发范式，同时经过几个项目的实践，也总结出了一套 ng 的最佳实践方案，目前新项目一般会采用 ng 进行开发。

但是 ng 本身概念比较多，除了大量的概念需要掌握外，也需要灵活的使用 TypeScript 和 RxJS 的各种常用特性，曾经面试过一个小哥，使用过 ng，但是 TypeScript 全是 any，RxJS 仅仅使用了 ng 的 HttpClient 发一下请求，这样的 ng 是没有灵魂的。

React Native

使用 js 来编写原生 APP 应用，通过 js bridge 来与原生进行通信，性能相对于混合开发来说好了太多，对于熟悉 React 的前端开发人员来说，上手难度也不大，TypeScript、Redux 什么的也依然可以使用，个人感觉对于前端人员来说是个切入 APP 开发的好路子，不过调试的坑实在是太多。

最近 flutter 异常火爆，除了嵌套确实是有点坑以外，调试难度比 RN 降低了好几个量级，因为公司业务并没有移动端的需求，只在个人项目中使用过 RN，对 APP 开发的了解不算非常多。

Redux

16 年使用的时候，还没有目前这么热门，现在已经算是非常常用的状态管理库了，在 React、React Native、Ng 中都可以使用，前端必学知识点之一。

Mobx

也是比较热门的状态管理库之一，在一个后台管理平台中使用过，个人感觉只适用于小项目，当项目状态复杂、多人并行开发的时候，会造成难以维护的问题，同时感觉状态管理不如 Redux 强大，响应式编程不如 RxJS 强大。

TypeScript

JS 的超集，带静态类型推断的动态类型语言，为 JS 引入了编译前的类型系统，如果写过 Go 一类的静态类型语言，会很容易体会到使用 TS 的好处，对于只写过 JS 的同学，也是了解静态类型的一个好工具， 前端必学知识点之一。

RxJS

JS 的响应式编程扩展，是了解并实践观察者模式的好工具，在处理各种同步、异步流的时候异常强大，内置了丰富的操作符。

17 年初的时候开始尝试在项目中引入 RxJS，并使用 React + RxJS 的方案进行项目开发，尝试直接使用 RxJS 来进行状态管理，但是尝试之后发现，RxJS 的主要优势在于对数据流的各种处理上，在单纯的状态管理上，并没有太大的优势，同时也有调试非常不便的问题，建议使用 RxJS 时， React 结合 Redux-Observable 使用，Ng2+ 结合 NgRx 使用。

如果没有接触过观察者模式的话，RxJS 在学习初期可能会有点难以理解，但是对于技术进阶来说，是一个相当好的知识点，前端进阶必学知识点之一。

NgRx

最开始使用 ng2+ 的时候，尝试着直接使用 ng 的 service 结合 rxjs 来进行状态管理，发现状态复杂之后非常难以维护，于是引入了 NgRx 来进行状态管理，NgRx 基本就是 ng2+ 版本的 Redux + Redux-Observable + RxJS，除了具体的 API 不一致，思想基本一模一样。

NgXs

使用过 NgRx 一段时间后，发现模板代码的代码量实在是过于庞大，于是在寻求解决方案的时候看到了 NgXs，官网上有这么一句介绍：

NGXS is modeled after the CQRS pattern popularly implemented in libraries like Redux and NgRx but reduces boilerplate by using modern TypeScript features such as classes and decorators.

目前还没有在项目中实际使用过，不过有各路大佬背书，考虑在合适的新项目中尝试一下。

Webpack

16 年的时候 webpack 1 的文档异常晦涩难懂，于是有了 Webpack 配置工程师的自嘲，基于 webpack 1 编写了一套适用于 Ng1 的自定义 loader，以支持利用自定义属性的 CSS 模块化方案，类似目前 ng2+ 的 CSS 模块化方案。

从 Webpack 2 之后文档就变得清晰多了，同时需要的配置项也少了很多，基本开箱即用，目前团队内 React 项目使用的是几年时间积累下来的一套稳定的配置，ng2+ 就直接使用 ng cli 了。

不过建议还是需要搞懂常用的概念及配置，毕竟在单页应用盛行的当下，webpack 是绝对绕不开的一个知识点，前端必学知识点之一。

Apollo GraphQL

Apollo 提供了 GraphQL 的全套解决方案，目前团队内对 Apollo 的使用也处于探索阶段，在 Ng 项目中尝试使用了一下 Apollo Client，目前体验不错，缓存、loading 状态、字段提示、service 自动生成等等都非常实用，学习 GraphQL 必备的库。

但是目前没有探索出很好的状态管理方案，更多的是当做一个请求库来使用。

Git Flow

git 的分支管理工具，多人协作的时候，分支管理是个很头疼的事情，目前团队内是参考 git flow 的标准在管理，和 Commitizen 一起用，分支管理就舒服多了。

Chrome 扩展

chrome 浏览器上安装的各种工具，一般习惯性的被称为 chrome 插件，但是按照开发文档的标准说法应该是 chrome extension，chrome 扩展程序。

本质上和开发一般的网页区别不大，就是往页面中注入 js 脚本，在代码结构上稍微有些不同，看看官网文档和书，基本一个星期就能上手了，公司业务中一般很少用到这个，用来做一些辅助自己的小工具比较不错。

JSON Schema

用来描述数据格式非常棒的一种语法。

预先定义好接口的输入输出格式后，结合 ajv 来进行接口校验，可以清晰的看到接口的输入输出是否符合预先定义的格式，再也不用在接口数据出错的时候排查半天啦。

Yeoman

用来开发脚手架的工具，曾经团队内使用这个开发了一个内部使用的脚手架工具，方便统一团队开发范式、初始化新项目、管理所有项目的配置文件升级等等，不过目前看来，属于已经没多少人用的工具了，github 仓库都已经好久没更新了。

二、后端

GraphQL

GraphQL 只是一种接口的标准，并不是具体的实现，各个语言都有各自实现了 GraphQL 的库，而且 GraphQL 虽然总是前端在提起，但事实上一门后端技术。

18年初开始尝试 GraphQL 相关的技术，到了下半年开始全面转向 GraphQL，最开始使用 Go + GraphQL，但是发现 GraphQL 在 Go 语言中的生态并不好，除了两个查询库，相关的工具实在太少，后续开始逐步转向 prisma 技术栈。

Nest.js

nest.js 是一个基于 node.js 的后端框架，框架本身就使用 TypeScript 编写，大量使用了装饰器语法减少代码量，同时框架设计基本和 Angular 一模一样， Module、Controller、Service、Guard、Pipe、Interceptor 等等，熟悉 Angular 的同学，基本一个周就能上手了。

nest.js 底层基于 express，也可以切换为 fastify，意味着很多老的 express 的中间件，可以直接拿过来用，生态方面问题不大。

如果前端同学想学习下后端的话，Nest.js 是个非常不错的选择，个人认为比 express，koa，egg.js 都要好。

Go

对于写 js 的前端同学来说，学习一门静态类型语言还是很有必要的，团队内后端正逐步向 Go 在转型，18年在两个项目中尝试使用 Go + GraphQL 来提供后端接口。

restful 类型的后端之前使用的 gin，新项目目前开始使用 iris，不过我还没了解过，有空了可以瞅瞅看。

ORM

写后端离不开 ORM，目前在 Go 里面使用过 gorm 和 xorm，但是感觉都不太好用，用起来不够顺心，如果在 node.js 中使用 ORM 的话，强烈推荐使用 TypeORM，对 TypeScript 的支持非常好。

Prisma

强烈安利的技术，一款基于 GraphQL 的后端解决方案，通过预先定义的 datamodel 数据模型，自动生成相关的增删改查接口，可以简单理解成一个加强版的 ORM，但是又不仅仅是 ORM，可以让 GraphQL 贯穿前端、后端、数据库整个开发流程，非常 nice。

基本上只要写好 datamodel，一个 GraphQL 后端服务就出来了，可以极大的节省后端人力，前端一人即可完成整个项目的开发。

同时官方提供了数据管理平台 prisma admin，非常适合需要快速上线和数据高可配置性的数据展示型项目。

三、运维

Docker

万物皆可容器化，容器化之后项目部署、运维等等都方便了不止一点点，我自己的服务器上部署的东西也全都使用 Docker 容器了，Gitlab CI + Docker，个人的小项目非常适合。

团队 16 年底开始尝试使用 docker ，17年所有前端项目都采用容器进行部署，但是由于团队并没有专业运维，容器仅仅起到了一个部署的作用，19 年孙大佬强力加盟之后，所有项目开始迁移 k8s，CI/CD 流程也开始规范化起来，方便了不止一点点。

Nginx

目前团队内的所有前端项目，基本都是编译成一堆静态资源之后，放入一个 Nginx容器中，简单快捷。

cnpm

淘宝出品的 cnpm，客户端经常被喷不好用，但是用来自建 npm 私有源还是非常方便的，加速和托管私有包都是比较实用的功能。

Minio

基本就是 S3 的开源版本，非常适合自建对象存储服务，如果嫌 OSS 贵的话，自己在服务器上跑个 Minio 是个非常不错的选择，目前公司内部的 cnpm 私有源接入了 minio，所有 tar 包都存在 minio 上了。