这才是看能力的地方，软件工程的能力比用什么新技术之类的重要多了，推荐一本 https://book.douban.com/subject/35006892/ ，我挺赞同这里面的挺多想法的，很多自己也实践过。
ETC （ Easier to change ），书里强调是一种价值观，我觉得也是，而且是最重要的一条，所有的事情从设计的时候就得考虑，他是否易于变化。做每一个决定也都要考虑，这个决定是否能做到易于变化，这样落实到代码的时候我们就会拆分的更清楚。
DRY (Don’t repeat yourself)，这个我最初的理解其实是浅见，只是想如果能自动化的就不要手动，这本书里给的了启发，避免重复其实就减少了维护的难度，特别是代码逻辑里面，这会让我们意识到，我们可以把逻辑拆分的更细，更易于变化，然后通过组合来去呈现复杂的逻辑。
正交性，如果能设计成完全不相干的系统就尽量不要有关联，消除不相关的事物之间的联系，这个最近有体会，因为一些原因我们很难做 SSO，所以我们的 portal 提供给各级子项目 token，而这其中还传递了其他的 profile 信息，其结果就导致了其他的系统出了问题，一直找不到原因，结果发现是 profile 信息因为某些权限问题传空了，结果就成了跨系统的问题，所以设计的时候一定要尽量做到正交。
封装，组件化，前端现在已经很容易能做到组件化，特别像 react，组件化是常态，重要的是如何能在多个系统 share，如何能够更方便的提出组件，提取出公用 utils，这个很推荐 monorepo 的方式组织代码，我们可以很方便的在一个项目里很容易的拆分出相应的公共部分，组件，逻辑，工具等等，可以结合 nexus3 这样的私有代码仓库，做到多个项目的 share
领域模型，构建前端的领域模型，只用通过稳定的模型去映射组件才能有更好的维护性，设计好领域模型后我们可以把后端的 api 映射到领域模型，然后前端的领域模型去映射组件，当然最好的办法是直接上 GraphQL.
code review，以上所有的东西都需要 code review 去统一和实践以及监督，这是落实这些东西最重要的一部，否则每个人都有不同风格，当然我们做的更多一些，比如通过 Prettier，以及 eslint 去定制一个我们的规则，通过 SonarQube 去看代码质量等等。
编码前：编码规范、最佳实践、登录鉴权
编码中：脚手架（飞冰 GUI 工具、yeoman 或者自研）、构建器（自研框架、webpack、gulp、npm scripts）、代码校验（自研系统、git hooks 等触发，然后调用 ESLint、Jest、CI 等）
编码后：发布工具（自研系统、ftp 脚本、shell 脚本、CI/CD）
迭代：检测工具（代码冲突检测、发布版本冲突检测）
监控：
运维：
用户体验包括大不限于以下几点：
- 保证内容的快速展现，减少用户等待时间
- 保证操作的流畅度
- 如果是移动设备，应尽量减少设备的耗电量
随着个人终端设备和浏览器性能的不断提升，将渲染和路由工作交给客户端，服务器端 RESTFul API 只提供渲染HTML所需的json数据，这种形态的Web应用被称为SPA(Single Page Application)，单页应用有以下优点：
- 减轻了服务器的资源消耗
- 与HTML文档比起来，JSON数据的体积小了很多，减少了网络请求的时间消耗
- 页面路由控制更快速灵活
- 可以离线使用
同时，SPA也会带来新的问题： - 浏览器需等待Javascript文件加载完成后陈才可以渲染后续的HTML文档内容，用户在等待的工程中页面是空白的，既“白屏时间”
- 客户端和服务器端编程语言不同，可能会存在一些诸如数据格式的差异，甚至路由逻辑冲突，增加了维护难度
- 不利于常规的SEO爬虫
前端工程化的衡量标准：快、准、稳
开发的快体现在保证质量的前提下，尽可能提高产品的开发速度
测试的快体现在尽量减少低级的逻辑错误，降低集成测试阶段消耗的时间成本
测试的准体现在测试阶段对问题的准确定位
从部署角度衡量工程化主要体现在稳
构建流程可以确保前端工程师能够使用有助于提高开发和维护效率的框架、规范进行源代码的编写，比如使用ECMAScript 6/7 规范编写Javascript, 使用LESS/SASS等预编译工具编写style, 使用AMD/CommonJS等模块化方案进行模块化开发等。此外，构建还具备图片压缩，自动生成CSS Sprite等功能，进一步减少了繁琐的人工操作。
构建流程解决了开发层面的问题
- Es规范与了浏览器兼容性不一致
- CSS的弱编程能力
- 资源定位
- 图片压缩/base64 内嵌/CSS Sprite
- 模块依赖分析和压缩打包
本地开发服务器须具备以下功能
- Mock服务
- 支持SSR, 前提是本地服务器与线上服务器使用相同的编程语言
- 动态构建，浏览器自动刷新
静态资源和动态资源分离部署
前端工程化是一系列工具和规范的组合，规范为蓝本，工具为实现。
其中规范又包括：
- 项目文件的组织结构，比如使用目录名称区分原文件和目标文件
- 源代码的开发范式，比如使用既定的模块化方案
- 工具的使用规范，比如工程化自身的配置规范
- 各阶段环境的依赖，比如部署功能的实现需要目标服务器提供SSH权限
工具的作用是将规范具化为具体功能并且在一定程度上将开发者限定在既有规范内。
管理平台形态的工程化做到了以下几点：
- 淡化环境差异性，保证构建产出的一致性
- 权限集中管理，提高安全性
- 项目版本集中管理，便于危机管理，比如版本回滚等
前端工程化最终的完美形态，必然与整体工作流结合，作为持续集成方案中的一环。
工程化整体架构：
- 以Yeoman为内核的脚手架
- 以Express承载的本地服务器
- 以Webpack为内核的构建系统
- 基于SFTP协议的远程部署功能
脚手架的功能：创建项目初始文件
脚手架的本质：方案的封装
脚手架工具要解决的最切实问题，简单概括就是:
- 快速生成配置
- 降低框架学习成本
- 令业务开发人员关注业务逻辑本身
构建还需要包括以下功能：
- 依赖打包
- 资源嵌入
- 文件压缩
- hash指纹
构建需要解决的问题可以归纳为以下3类：
- 面向语言
- 面向优化
- 面向部署
