微店技术周刊(总第 27 期)-本期主编-张尚金

[hoperyy]

微店技术周刊(总第 27 期)-本期主编-张尚金

别人的看法都是狗屁，你是谁只有你自己说了才算 --《哪吒之魔童降世》

关于

微店技术周刊整理每周有趣有用有料的各类内容，为大家呈现多样的技术世界。

周刊编辑：@何会会 / @张尚金 / @杨力 / @赵兴 / @刘远洋

周刊招募内容作者，主题不限，发出你的声音吧！

周刊同步在 微店技术团队 github，欢迎关注：https://github.com/weidian-inc/weidian-tech-blog

分享

• vue3.0 面向函数写法的思考(推荐者: @张尚金)

  面向函数的写法为什么能方便的解决逻辑复用的问题（vue 目前版本存在的痛点），看看尤大是怎么思考的吧！

• 架构师技术图谱，助你早日成为架构师(推荐者: @张尚金)

  架构师技术图谱包括：分布式、前端、大数据、存储、微服务、推荐系统、框架 、消息队列、编程语言、设计模式、重构、集群等内容。

• 前端离线化探索(推荐者: @张尚金)

  高速公路、地铁隧道、楼道角落，以及诸多日常信号不稳定区域，这些场景日常经常碰见，那我们该如何改善用户的焦虑，带给他们更好体验，从而提升用户留存与口碑呢？

• 创建动画 Logo 的技术教程

  利用 SVG 来创建 Logo 动画的一篇教程，给 Logo 加点动画，网站或许会更吸引人哦~

• CSS 布局教程大全

  这里汇总了丰富的布局场景和案例，对于新手，可以快速的入门 css 布局，对于老手，也能学到一些更好的布局处理方式。

• 如何编写一个高性能的 slider 组件

  为应对越来越丰富的动画场景，浏览器有个专门用来处理动画的 GPU 进程，这其中就包含一个专门处理 3D 动画的绘图协议 WebGL，这篇文章就是介绍了如何通过引入 WebGL 来使我们的 slider 组件更加顺滑流畅。

• GitHub 公布托管平台与美国贸易管制的相关细节 (推荐者: @刘远洋)

• HTTP 安全 Headers - 完整指南?(推荐者: @罗炜)

  介绍了常用的事关安全的 headers

• Vue 源码拆解（一）：实现计算属性和侦听器(推荐者: @罗炜)

• 构建自己的文本编辑器简明教程(推荐者: @刘远洋)

• 详细介绍 Apache Licene 2.0 协议(推荐者: @刘远洋)

• 学习 underscorejs 整体架构，打造属于自己的函数式编程类库(推荐者: @刘远洋)

• [译] 愿未来没有 Webpack(推荐者: @赵兴)

• 深入理解 Node.js 中的进程与线程(推荐者: @何会会)

• JS Promises: race vs all vs allSettled(推荐者: @张尚金)

  promise 的一些你可能不知道的使用细节

• 前端进阶必备，github 优质资源整理分享！(推荐者: @刘远洋)

编程之外

• 程序员工作法(推荐者: @张尚金)

  掌握主动权，忙到点子上，8 条程序员工作法助你职场上的我们

• 应急响应实战笔记(推荐者: @张尚金)

  面对各种各样的安全事件，我们该怎么处理？这是一个关于安全事件应急响应的项目，从系统入侵到事件处理，收集和整理了一些案例进行分析。

• 提升网站体验的一些设计思考(推荐者: @张尚金)

  良好的用户体验能够留下更多的用户，所以我们应该为追求好的体验而不断努力改进

• 一些能够提供设计效率的 sketch 插件汇总(推荐者: @张尚金)

  好的工具真的能大大的提升工作效率，这里汇总了一些很有用的 sketch 插件，比如可以快速的从 Unsplash 里面选取照片用于 UI 设计等

投稿

【思考】微店前端工程化的迭代史.md

@刘远洋 - 生产力平台

原文链接：hoperyy/blog#145

正文部分

微店前端工程化起步于一个内部产品 vbuilder，对外我们有一个开源版本 bio-cli。

去年我们也写过一篇文章介绍该产品： bio: 一站式前端开发工具。

这么长时间过去了，我们在前端工程化方面有了哪些变化、遇到了哪些问题、用怎样的方案解决这些问题等等，值得为大家再分享。

V0.0

这里也就是介绍下背景，为什么我们会开发 vbuilder。

总体思路就是：将重复性工作集成化。

当时，团队面临几个问题：

• 重复：每个项目要新开一个脚手架（webpack / gulp 之类）
• 混杂：工程目录既包含脚手架文件，也包含业务文件
• 混杂：packge.json 中的依赖既有脚手架的依赖，也有业务依赖，难以区分
• 难更新：脚手架一旦确定，几乎不再更新，如 webpack 1.0 的项目极有可能会一直维持在 webpack 1.0 状态
• 协作：团队协作中，项目的技术栈纷杂，不同人员维护同一个项目成本高昂，如：需重新理解对应工程配置等

总结为下图：

基于以上问题，我们开始了 vbuilder 的研发。

最终产品以命令行的形式发布。

此时的 vbuilder 为 V0.0 状态。

V1.0

vbuilder V1.0 提供了以下能力：

• 默认命令集：内置一套命令集，用于常见功能开发，包括 mock / update / help 等
• 静默更新：用户安装一次命令即无需关注更新，其更新自行静默完成
• 收敛脚手架：将工程内的脚手架配置隐藏，并统一管理，开发者可快速聚焦业务逻辑
• 开放接入脚手架：不限制技术栈类型（vue / react / angular / weex 等），开放接入不同技术栈
• 插件化：除内置命令集外，插件化扩展命令集，供团队同学实现订制逻辑

vbuilder 的不断推进下，我们欣喜地看到，团队发生了一些变化：

• 便捷：新项目一个命令即创建，直接开始业务开发
• 纯粹：工程目录只保留了业务文件，脚手架等工程配置被隐藏
• 更新：脚手架被收敛为统一管理，统一更新，尽可能应用最新的技术栈
• 协作：绝大部分项目协作的成本范围收敛到 “业务逻辑”，剔除了 “工程配置逻辑”，协作成本大大降低
• 开放：在收敛脚手架配置的同时，开放性接入各类技术栈脚手架，如 weex / vms / 后台管理 / serverside project 等
• 协作：团队统一性的技术更新得以快速进行，不会再遇到因工程配置不同不断适配的问题

总结为下图：

V1.0 出现后，推进的很顺利，在推进过程中秉持如下原则：

• 提效：帮助业务开发者节省时间
• 共担：开发者参与生态建设（脚手架开发维护、插件开发），至少在绩效上会得以加分
• 好用：使用方式简单好用，才让人有用的欲望

V1.0 基本解决了以下角色的痛点：

• 后端同学：内部系统开发场景被 100% 覆盖
• 前端同学：绝大部分业务场景被覆盖
• 脚手架开发者：强大的脚手架被开发好后，得以快速推广
• 插件开发者：自定义命令，满足个性化开发

V1.0 的问题

• 封闭性

  高度定制化的工程配置需求实现难度增大

  脚手架配置的主题被隐藏，虽然仍然开放给开发者一些配置性文件，对于高度定制化的配置需求而言依然杯水车薪。

  此时，就必须新开一个脚手架，重新接入 vbuilder 体系。

  在 “开放性” 来说，打了折扣。

• 插件开发的冲突

  由于 vbuilder 是基于命令行开发，插件开发者扩展自定义命令式，依然是自定义命令行，团队规模不断扩大的状态下，很容易出现不同插件使用同一个命令，被同时安装的状态下，重复执行该命令。

V2.0

V2.0 至少要解决 V1.0 存在的问题，同时需要有更明确的发展方向。

不过，V2.0 依然基于命令行。

V2.0 如何解决封闭性问题

V1.0 的思路是 “闭合”，虽然有一定的开放性，但仍然不够。

V2.0 新增 “开放” 的能力，脚手架配置可以被隐藏，也可以随时在需要的时候暴露在工程配置中，进行定制化开发。

当然，会遇到脚手架难以统一管理的问题，这一点仍然有办法可以解决。

因为被暴露的工程配置是 vbuilder 提供的，vbuilder 得以方便地统计哪些项目使用了自定义的脚手架，将通用型工具包下发给该工程。

V2.0 如何解决插件开发的冲突

• 问题 1：插件间的冲突

  举个例子，有两个插件中，都有一个命令 run。如果用户安装了这两个插件，在执行 run 命令的时候，两个插件的逻辑均会触发。

  在某些情况下，这不是用户希望看到的场景，可能 TA 希望的只是运行插件 A 的命令 run。

• 问题 2：插件命令集与内置命令的冲突

  例如，内置命令集中有命令 init，而某个插件也有 init。

  那么在用户执行 init 命令时，依然会执行两遍逻辑。

• 怎样解决？

  我们组合使用了以下方案：

  • vbuilder 检测是否有重复命令，如有，提示用户是都运行、还是选择运行某一个插件中的命令

  • 为命令圈定生效条件

    vbuilder 的命令行基于 commander。我们基于 commander 扩展了一些方法。

    假如我们希望，插件中的命令 show 只在工程目录中 xx.show 文件存在的情况下生效，那么代码如下：

    commander
    .command('show [param]')
    .effect(cwd  => fs.existsSync(path.join(cwd, 'xx.show'))) ---- 这是我们扩展的命令
    .description('我的自定义命令')
    .action((param, options) => {
    	console.log('my show');
    });

  • 为内置命令集声明其为“内置命令”，插件命令可以阻止内置命令执行
    假如插件中有个命令 init，而 vbuilder 内置命令中也有 init，我们希望插件中的 init 命令生效，内置命令不生效，该怎么做呢？

    我们扩展了 commander 的 2 个方法：declareDefault 声明内置命令、preventDefault 阻止内置命令执行。

    定义内置命令时，代码如下：

    commander
    .command('init [param]')
    .declareDefault() --- 声明内置命令
    .description('内置的 init 命令')
    .action((param, options) => {
    	console.log('init inside');
    });

    开发插件命令时，代码如下：

    commander
    .command('init [param]')
    .preventDefault() --- 阻止内置命令执行
    .description('内置的 init 命令')
    .action((param, options) => {
    	console.log('init inside');
    });

    Commander 的源码只有 1000 行左右，逻辑还是很清晰的，扩展起来非常方便，这里不再列举实现。

V2.0 的新功能

在命令行这个场景下，我们把 vbuilder 定义为公司内部开发的一个“水电煤”性质的基础设施。

通过 vbuilder，我们新增了以下场景：

• 支持 chrome 插件 es6/7 化开发
• 支持组件库快速开发
• 支持 js 工具库快速开发
• 支持快速打开文档库等等

得益于插件化，通过充分调动开发者积极性，我们可以将其能力无限延展。

V3.0

我们目前还没有进入 3.0 的开发，但有一些方向是我们可以尝试的：

• cloudIDE（内部已有该类平台）
• vscode 定制化 IDE，该类场景在超大型团队比较适合，IDE 定制化开发有更多的应用场景，更快的开发效率
• 云化（其实不算新了，很多公司已经实现了云化）

这是目前我们在微店前端工程化领域的一些实践和思考，希望对大家有帮助。