典型技术选型
集客顾客端脚手架搭建
选型背景
将第三方 SDK 打包为链接，类似于 <script src="打包后库的地址?deployId=部署ID" name="唯一标识符"></script> 这样的一个链接，实现粘贴代码即可完成部署。
技术选型过程
考虑到的方案有 rollup、jQuery、原生 js，鉴于这些方案的实现都比较复杂且没有积累，最终采用 webpack 脚手架。
其实更好的实现方式使用原生 js 写，加载速度更快。
集客顾客端组件优化
选型背景
在将客服组件上线后，由于未考虑到加载的组件包的大小，尤其是初始加载的包比较大，即使是压缩过初始加载也有 600 多 k，严重影响首页加载，导致加载此脚本的网站需要很长时间才能响应
技术选型过程
考虑到的方案有
- 组件异步加载，减少首屏加载，非首屏的较大的组件可以预加载（预加载没想到）
- 轻量级库：
- 所有 UI 组件自己编写，保证只写需要的组件
- 去掉较大的依赖库
- 移动端、桌面端的分开打包，参考拓客（没想到，我想到的是移动端另开一个新项目）
- 代码分层，尤其是 IM 层要分离出来（没考虑过这方面）
轻量级网站构建
选型背景
微信端的问卷调查，需要在三端（桌面端、移动端、微信端）同时兼容
技术选型过程
- 后端渲染模板（未想到），以下是一些缺点
- 后端渲染对 CPU 的要求较高
- 打算用 oss 来减少后端渲染，但考虑到表单经常变化，且分享的链接要尽可能的保持不变，这就限制了 oss 的使用
- 由于分享的链接要尽可能的保持不变，在新的表单分享模板加入后需要后端刷数据，容错性较低
- 最终方案：采用前后端分离的方式，用原生语法新框架写，本来打算采用官网脚手架，但考虑到官网脚手架只能在 node v9.11.2 版本下使用，且不支持 ES6 及以上的语法，决定在 generator-webapp 脚手架的基础上改造
总结
选型共性
优点
- 比较看重开发的效率性，会避免自己不熟悉的领域，开发比较快
- 尽可能的寻找各种选型，会从前端的各种方面优化
缺点
- 比较看重开发的效率性，会避免自己不熟悉的领域，少了一些技术上的尝试（新项目尝试新技术）
- 对选型背景不够了解，选型的技术方案考虑的不够全面（加深知识的广度，了解一些后端、前端新知识）
- 没有分析技术的优劣势，以及可能存在的风险（列出技术方案时应给出优缺点，以及实现的风险）
- 基本没有考虑到代码的架构（适当关注一下代码架构）
- 没有从多方面考虑，比如从后端、需求的角度（同样加深知识的广度）
- 没有参考市面上同类产品已经成熟的技术（选型时注意参考市面上已有的成熟技术）
选型经验教训
- 对于新的技术方案，先验证后使用，最好参考市面上同类已有的成熟技术
- 深化知识广度，建立知识索引
- 了解需求背景，有时可以从非技术的方面突破
- 适度尝试新技术