女王控的博客

2019年技术选型总结

典型技术选型

集客顾客端脚手架搭建

记一次组件打包为链接的实践

选型背景

将第三方 SDK 打包为链接,类似于 <script src="打包后库的地址?deployId=部署ID" name="唯一标识符"></script> 这样的一个链接,实现粘贴代码即可完成部署。

技术选型过程

考虑到的方案有 rollup、jQuery、原生 js,鉴于这些方案的实现都比较复杂且没有积累,最终采用 webpack 脚手架。

其实更好的实现方式使用原生 js 写,加载速度更快。

集客顾客端组件优化

构建多平台轻量化组件的实践

选型背景

在将客服组件上线后,由于未考虑到加载的组件包的大小,尤其是初始加载的包比较大,即使是压缩过初始加载也有600多k,严重影响首页加载,导致加载此脚本的网站需要很长时间才能响应

技术选型过程

考虑到的方案有

  1. 组件异步加载,减少首屏加载,非首屏的较大的组件可以预加载(预加载没想到)
  2. 轻量级库:
  3. 所有UI组件自己编写,保证只写需要的组件
  4. 去掉较大的依赖库
  5. 移动端、桌面端的分开打包,参考拓客(没想到,我想到的是移动端另开一个新项目)
  6. 代码分层,尤其是 IM 层要分离出来(没考虑过这方面)

轻量级网站构建

轻量级网站构建实践

选型背景

微信端的问卷调查,需要在三端(桌面端、移动端、微信端)同时兼容

技术选型过程

  1. 后端渲染模板(未想到),以下是一些缺点
  2. 后端渲染对 CPU 的要求较高
  3. 打算用 oss 来减少后端渲染,但考虑到表单经常变化,且分享的链接要尽可能的保持不变,这就限制了 oss 的使用
  4. 由于分享的链接要尽可能的保持不变,在新的表单分享模板加入后需要后端刷数据,容错性较低
  5. 最终方案:采用前后端分离的方式,用原生语法新框架写,本来打算采用官网脚手架,但考虑到官网脚手架只能在 node v9.11.2 版本下使用,且不支持 ES6 及以上的语法,决定在 generator-webapp 脚手架的基础上改造

总结

选型共性

优点

  1. 比较看重开发的效率性,会避免自己不熟悉的领域,开发比较快
  2. 尽可能的寻找各种选型,会从前端的各种方面优化

缺点

  1. 比较看重开发的效率性,会避免自己不熟悉的领域,少了一些技术上的尝试(新项目尝试新技术)
  2. 对选型背景不够了解,选型的技术方案考虑的不够全面(加深知识的广度,了解一些后端、前端新知识)
  3. 没有分析技术的优劣势,以及可能存在的风险(列出技术方案时应给出优缺点,以及实现的风险)
  4. 基本没有考虑到代码的架构(适当关注一下代码架构)
  5. 没有从多方面考虑,比如从后端、需求的角度(同样加深知识的广度)
  6. 没有参考市面上同类产品已经成熟的技术(选型时注意参考市面上已有的成熟技术)

选型经验教训

  1. 对于新的技术方案,先验证后使用,最好参考市面上同类已有的成熟技术
  2. 深化知识广度,建立知识索引
  3. 了解需求背景,有时可以从非技术的方面突破
  4. 适度尝试新技术

评论

阅读下一篇

使用&#x3000;等空格实现最小成本中文对齐
2020-01-20 10:29:05
0%