一个小程序开发者的技术之路 | 2018掘金年度征文

这是我在掘金的第一篇原创文章，主要是总结一下2018年技术上的学习与思考，也想对2019年进行一下规划和展望。

2018 从小程序开始

2018年，是我工作的第二年。17年，主要的学习和实践的技术是vue，我们组用vue做了一套 sass 化的商城系统。但是17年末，因为公司业务的调整，在18年初，我们组专注于了小程序的开发。

在经过独立负责前端开发一个比较小的礼品卡小程序之后。我们组开发的第一个小程序是某手机品牌商城。在这一年中我大概参与了八九个小程序的开发，从开始小程序的商城，到目前在做的智慧门店项目。

首先想谈的是选型，我们当时有原生，mpvue 和 wepy 可选。当时的考虑是想既然是新的东西，要先了解它的本身是怎么写的，所以就选择了用原生开发。但是我们又很想用scss来写样式，所以使用了前端工具，主要是为了转换 scss。关于前端开发工具，我在之后的部分也会着重介绍。

其次，在小程序技术的学习上，在开始时，感觉没有遇到太大的问题，因为之前有vue的基础，所以转换为小程序的开发中，还算比较自然。在这一年里，我总结下来比较难的点有：

1. 实现一些复杂的效果的时候，小程序有一些瓶颈。比如小程序的性能，比如一些内置的组件一些事件想修改的时候，没办法完全的修改和控制，有些还有兼容性问题。例如video组件对播放条的控制。需要多去研究，微信开发者社区也是一个好地方。
2. 对于小程序授权的控制。因为小程序对授权管理还是比较严格的，而且需要授权的规则也在改变。在整个商场系统中，什么时候获得权限，可以拿到比如 UnionId，头像等，需要在开始时就讨论和设计好。
3. 小程序性能的优化。现在还只是在优化接口的请求，尽量减少无用或者复用的接口。在未来也希望有更多的探索。

小程序cli工具和前端工程化浅尝

在18年9月份左右的时候，当时我们组内已经做了十几个左右定制化的小程序商城。但是在这个过程中，我们写了一些UI组件和业务组件来加速开发，无论是样式组件，或者是对接后端的业务组件，都没有一个统一的管理，碎片化比较多。可能不同的商城实现同样的功能的时候，是两套代码。加上之前是用的别人写好的cli工具，所以这时候我的想法是自己写一个cli的工具，可以把样式组件和业务组件统一管理起来，并且进行版本控制。这样，在之后讨论中也逐渐明确了以下几个功能:

1. 把UI组件库，业务组件库和编译环境配置文件分别放到三个git仓库进行管理。
2. 能够初始化开发项目，cli工具可以把我们写好的组件库按照所需版本添加到初始化的项目里。这样刚初始好的项目的功能也是统一的。
3. 能够更新两个组件库以及cli工具自身。
4. 能够编译 scss 文件，并且解决 scss 在转为 wxss 过程中的重复编译和与wxss @import功能不同的问题（最后我们把 scss 文件分为两类，一类里面只写样式，一类里面写一些变量和有功能的语句，这个之后再写一篇文章细谈）。
5. 能更方便的切换开发环境（这是之前的工具就有的，这里做了一些扩展）

这是这个cli工具规划的一期的功能，以上的功能基本都实现了，也算运用了一点前端工程化的思想去管理我们小程序的开发，最后我完善了这个工具的文档并且上传到了公司私有的Npm源上。但是这个工具还是有个小遗憾，就是我 webpack 用的不好，在处理 scss 文件重复编译的问题上没有找到好的方法，最后是在百度出的比较 fis3 这个打包工具上找到了方法。但是 fis3 本最近也没有更新了，里面的东西都比较老，希望之后可以用 webpack 解决，把编译内核换成 webpack。

当然也通过这个小工具的编写，我也学了一些关于编写命令行工具的以及一点点node的知识。

Taro，一套 react 代码，编译多端小程序

年底的时候，我们有了支付宝小程序和钉钉小程序的一些探索。也希望可以一套代码编译多端小程序。我就尝试了一下把一个不是很复杂的小程序转换为Taro的项目。

当时选择Taro也是经过了一些比较，相较于其它的多端编译的框架， Taro 相对来说出来的比较早，用的比较多，github上issue解答比较多，脚手架工具也好用，也出了小册可以学习。 Taro有一个功能感觉很好用，只要在一个已经写好的小程序上执行 taro convert 可以把一套小程序代码转换为 taro 的项目。 虽然我们的小程序代码可能因为用