Iceworks: 从 GUI 开发工具到集成研发工作台
疾风知草劲，路遥知马力。在阿里，恐怕没有几个前端研发工具像 Iceworks 一样，历史悠久，历久弥新。iceworks 第一版本发布于 2018 年 3 月，至今已经走过了近两个年头。笔者于 2019 年 4 月和 @思忠 开始接手，借本文分享我在这个领域的一些经历和思考。
注：Iceworks 是 AppWorks（VS Code 套件）的前身，原先是基于 Electron 的集成研发工作台。
Iceworks 1.0 && 2.0
时间点：2018.3 ~ 2019.4
Iceworks 最初的定位是基于物料的 GUI 工具，产品形态是桌面客户端。这里面的出发点是通过该客户端，能够屏蔽前端工程环境和工程技术的复杂度，降低前端的研发门槛，让开发者能够快速地上手前端项目的开发。
2.0 是怎么做的？
为达到这样的目标，iceworks 2.0 有两个基本思路：一个是通过物料提升研发效率，第二个是通过 GUI 简化工程链路的使用成本。围绕着这两点，iceworks 2.0 形成了从通过模板初始化项目，到用区块搭建页面，再到通过可视化方式调试和构建项目、进行代码版本管理（Git），最后发布前端静态资源到 CDN 的开发工作流。
下图囊括了 2.0 主要的功能点：
在产品的组织中，因为是「基于 AppMaterial（物料）」，所以物料占据了最大的比重；因为要「简化工程使用成本」，所以工程操作放在了最显著的位置，并且内置了 npm 和 Node。
这样的思路是否有效？还需要有数据的去分析做得怎么样。
但在这一方面，作为开发者，我们并没有足够的做产品的经验：iceworks 2.0 的数据采集只停留在了 DAU 和一些零散的操作次数的计数上。掌握的数据不足以进行有效的产品分析。而作为桌面客户端没有主动（强制）升级机制，所以版本的分布原因造成在补充数据采集后还需要一段时间进行数据积累。在这个阶段，我们能够知道只有：
- 每天的 DAU 是 800+，且维持了很长一段时间；
- 平均每个用户一天会启动 Iceworks 两次，每五个用户当中就有一个会在当天退出 iceworks，整体的使用时长不高；
- 平均每天有近一半的用户使用模板创建项目，超过一半的用户使用区块创建页面，用户使用最多的功能是启动调试。
这就是产品的现状。
技术上，为实现跨平台的桌面客户端，选择了使用基于 Electron 的架构：渲染进程中加载的是一个 ICE 1.0 构建的前端应用；主进程则是一个“自研”的 Node 应用，负责操作项目文件和执行 npm 命令。两者通过 Electron 提供的 IPC 进行通信，渲染进程通过 remote 使用主进程模块。下图是 2.0 的技术架构：
前端应用里面有几个比较大的模块：
- Library: 一些工具库，例如操作文件的通用封装 FileSystem、Git 常用命令封装 GitTools、管理项目依赖的封装 ProjectScripts 等；
- View: 传统的 React 视图层，遵循着通过可复用组件组织页面的结构，其中项目页以类插件的方式封装了操作面板。View 内会去调用 Library 的能力，也会直接通过 remote 去调用主进程模块的能力；
- Store: 基于 Mobx 封装出的一系列的 Store，与 View 进行双向绑定。这里面既有全局的 Store，也有局部的 Store；Store 也会去调用 Library 的能力及主进程模块的能力。
Node 应用里面划分了以下几个模块：
- Base: 通用基础能力层，面向上层模块提供如日志调用能力（Logger）、数据打点能力（DataCollector）、应用数据存储能力（Storage）等；
- Sessions: 使用 node-pty 执行 Shell 命令的封装，通过 Manager 类管理实例；
- Scaffolder: 对项目文件的操作能力都封装在这一层，承担了 GUI to Code 的职责，例如创建页面、创建路由、创建菜单等；
- Services: 面向前端应用提供的服务层，所有可被前端调用的能力都封装在这一层。
这就是技术的现状。
2.0 版本的产品和技术有哪些问题？
产品上，从数据和用户的反馈来看，在日常开发中用户对 Iceworks 的依赖非常弱，通常只是用来初始化项目和启动调试，使用频率很低 —— 那么这个工具就成了一个食之无味弃之可惜的东西；为寻求突破，我们做了很多 PoC，频繁迭代过程中丢失了产品体验：监控后台每天堆积如山的 undefined 错误日志反映了产品稳定性不足，我们也投入了大量精力去进行用户答疑。
技术上，架构设计的不合理问题在迭代过程中开始暴露，从上面的架构图中可以看出：模块分层职责不清，模块间调用关系混乱；而功能烂尾和为赶功能而产生了产生了大量冗余和临时 Hack 代码，这些都成了技术的负债；另外一些需要投入大量精力建设的能力缺失，如持续集成能力、有效监控和日志的收集等。这些问题直接导致：
- 新功能的研发迭代周期长，往往两到三周才能进行一次版本迭代；
- 每次发布时间长：每次进行版本发布都需要半天时间，且胆战心惊；
- 产品问题全靠用户反馈，且很难复现事故现场。
这仿佛是马太效应，每况愈下。
在人员能力上，团队对如 npm 执行原理、node-pty 实现原理、electron-builder 还不能做到自主可控，遇到问题全靠查漏补缺。
Iceworks 3.0：“拨乱反正”，可视化辅助工具
时间点：2019.4 ~ 2019.10
为结束产品混乱的状态，还清技术债务以及建设团队人员能力，大概是在 19 年 4 月左右，我们启动了 Iceworks 3.0 版本的开发。目标是让产品更简单和友好，技术更稳定、更可维护和可扩展。
具体来说，3.0 版本做了什么？
为了让产品做到更简单和友好，我们对产品的组织结构进行了梳理，把工作台划分为项目开发、工程链路、物料管理和个性化设置四大部分。同时在项目开发中，有明确的价值引导。这背后的思考是：
- 工具要解决的核心问题始终是提效，提效核心应该是在项目开发的编码时，开发周期中 80% 的时间都在这个环节，所以项目开发是主模块；
- 工程提供的能力是辅助性的，开发者在开发时不会频繁地启动调试、构建项目和修改工程配置文件，所以工程是次要模块；
- 「基于物料」是我们的核心手段，但物料的管理和展示需要收敛，集中展示和管理，所以物料是单独的模块。
红色部分为新增功能，中划线部分为删减功能。
相对于 Iceworks 2.0 来说，iceworks 3.0 做了一些加法，目的是为了**「更好用」**，这些加法有：
- 配置可视化操作：降低框架和工程配置的理解和编码成本，例如应用的路由配置、页面的菜单配置、工程的构建配置等都可以通过可视化的方式操作修改；
- 多主题：都 9102 了，还只有一个浅色？
- 多语言：为国际化做铺垫。
相应的，也做了一些减法，目的是为了提高投入产出比：
-
下线掉高错误率和搞维护成本的功能，例如终端：一是绝大数命令行交互的都可以通过 GUI 的方式完成，二是团队没有精力和能力维护好这块内容；
-
下线掉低使用率的功能，例如自定义模板和通过区块组合搭建页面，下图反映这两个功能在 2.0 的使用情况：
在技术上，新架构基于 Web。这样的架构模式在一些成熟的桌面客户端中均有实现，例如 VsCode 和 Theia。基于 Web 的架构可以在命令行工具、桌面客户端和在线版本间更好地进行适配，下图是 3.0 的技术架构：
对于 Iceworks 这样的产品形态来说，它的前端应用架构复杂度不应过高。主要要解决的问题是如何组织视图的模块结构、如何做状态管理、如何与服务端进行双向通信。在此过程中，我们沉淀出了 icestore 这样的轻量级状态管理方案。
在服务端，使用 midway 做了一个轻量级的 Node 应用，只有三个路由：项目操作相关的、物料管理相关的、个性化设置相关的。服务端承担的职责是对项目本地文件的操作和执行 Shell 命令。
在服务端，对 GUI2Code 对应的操作都可以模块化，例如是操作路由、菜单还是页面？这些子模块的 API 是固定的，只是背后的实现有所差别。因此，我们抽象了 Adapter 这一层，总结可操作的模块有哪些，操作的内容有哪些，标准化接口，实现基础操作包，完成对 ICE 官方项目的支持。如果需要支持其他类型的项目（CRA/Vue），则可以继承基础包进行扩展，又或者只遵循标准接口实现自己的操作包即可。通过这样一套模式，即可做到对 ICE 不同版本项目的兼容，又可以扩展支持其他类型的前端项目，提升了应用架构的扩展性。
关于 icework 3.0 版本的 Adapter 模式后续会有详细的文章介绍，这里不再展开。
有了合理的分层，再去做数据采集、日志监控或单元测试就方便多了。
吸取了 2.0 版本在数据采集上的疏忽，在 3.0 中，我在 socket 的分发层收集所有用户的操作，这样便把数据细分统计到用户在哪个域下（项目/工程/物料/设置）的哪个模块（Git/Menu/Page）执行了什么动作（create/delete/update）。这样便可以比较完整地统计到所有的功能使用情况，利于未来进行产品分析。
在日志监控上，前端使用封装的 Logger 工具库打日志， Eslint 禁止在代码内使用 console，Logger 中使用 ARMS 进行前端监控和收集错误日志；服务端借助 egg-logger 的 transport 能力，在生产环境中将指定 level 的日志收集到 SLS，对日志持续进行分析和监控。
3.0 的实施效果如何？
可以从以下几个维度去看产品：
- 自 Iceworks 3.0 发布以来，有 30% 的用户已经迁移到了 CLI 的使用链路，每天安装量稳定在 40 左右；
- 相对于 2.0 版本来说，人均创建页面次数提升了 24%，人均使用模板次数提升了 45%；
- 新加入的功能中，几乎所有用户每天都会使用创建菜单功能，每两个用户就会使用一次创建路由功能，20% 的用户使用了新的暗色系皮肤。
得益于 Adapter 层，新版本的所有功能对 ICE 新老项目都达到了 100% 的支持……
在技术上的收获则更大：
- 在减少了 37% 的代码量前提下依然在 3.0 版本中实现了 Iceworks 2.0 内 90% 的功能；
- 从** 0 测试**到针对 Adapter 层的测试实现了 65.54% 的行覆盖率；
- 提升 51% 的有效错误日志覆盖率；
- 发布时间由半天缩短到了 30 分钟；
- ……
沉重的技术负债在这一版本中终于得到了解脱。
Iceworks 4.0：“寻求突破”，集成研发工作台
时间点：2019.10 ~
为什么要做 Iceworks 4.0？
在 icework 3.0 功能稳定后，摆在我们面前有几个问题：
- 如何处理 Iceworks 2.0 的桌面客户端版本；
- 如何突破性地提效与降低门槛，引领研发模式进行升级；
- 如何更好地服务淘系中后台业务研发。
对于第一个问题，一个简单粗暴的方式就是将 3.0 版本包一层 Electron 的壳，这就成了新的桌面客户端版本，然后让用户升级上来。但是以现有提供的辅助性功能来说，没有提供一个桌面客户端的必要。市面上桌面客户端形态的开发工具主要有两种，一种是专注于解决单点问题的软件，例如 iHosts、Beyond Compare、Sourcetree 等；另一种则是 IDE，如 Atom、Xcode、WebStorm 等。3.0 可视化辅助工具的特性做成桌面客户端没有明显的收益点。
对于第二个问题：
- 可行性的方向有辅助编码的编辑器插件，例如 VsCode 插件、Sublime 插件等；又或者是各类浏览器插件，例如 Chrome 插件、Firefox 插件等；但对于我们团队的定位和要解决的问题来说，单点的桌面客户端工具、编辑器插件、浏览器插件都不足以对淘系中后台业务提供完整体系化的研发模式。只有面向垂直领域去做开发链路的集成才能降低门槛，关注编码时才能提效，同时对开发体验进行评估，对开发效率进行衡量。
- 而在研发模式的判断上，我们认为随着 severless 等云化技术的流行，开发者的编码将会大量地在线化，使用 WebIDE。面向未来的云端研发模式我们需要提前布局。
对于第三个问题，淘系中后台业务研发将会升级到小二工作台产研平台中完成，产研平台将在线上完成研发流程的流转。这就更需要我们在云端研发模式上有所作为。
因此，我们将基于编辑器去做全新的研发工具，这就是 Iceworks IDE 的想法：
- 通过 IDE 的方式为中后台业务提供研发标准化流程，定义符合场景域的研发模式；
- 技术架构上基于 Web，能够同时产出桌面客户端和在线版本；研发模式的 GUI 能力通过 IDE 插件的方式实现，同时在两个版本中都能够使用；
- 推动淘系小二工作台在线化研发，在线上就可以完成整个研发流程的流转；
- 在源码中提供可视化搭建能力，探索 Low Code 和 Pro Code 的结合。
IDE 只是一个方向，具体应该怎么做？
红色部分为新增功能，中划线部分为删减功能。
在我们的计划中，iceworks 将会覆盖先前版本中的大部分功能，同时，重点建设以下能力：
- 基于物料进行可视化开发，例如在源码编辑时直接插入组件或区块代码（物料面板）、通过可视化的方式配置组件的属性和样式、通过可视化的方式开发自定义物料源；
- 通过拖拽搭建的方式辅助编码：对于视图层来说，可以完全通过可视化的方式搭建物料（组件/区块）、通过组合区块和配置的方式搭建模板；对于应用开发来说，提供源码与搭建能够同时使用的混合开发模式，在预览页面时可以通过可视化拖拽元素的方式进行布局调整。
- 通过可视化的方式设置配置，例如前端框架层的配置、工程的配置、状态管理和数据源都可以通过可视化的方式进行设置；
相关功能将逐步以 PoC 的方式进行，持续探索和定义符合中后台业务的 IDE。
技术上如何实现这样一个 IDE？
在 Iceworks 4.0 的技术架构中，IDE 底层技术基于阿里集团 IDE Framework，我们封装本地 IDE 的集成能力，沿用 Iceworks 3.0 中适配层的能力封装出 IDE 插件，构建出本地的桌面客户端。下图是 4.0 的技术架构：
关于 Iceworks 4.0 的技术架构未来会有详细的文章进行介绍，这里不再展开。
衡量标准是什么？
罗马不是一天建成的。iceworks IDE 目前仍处于内部测试阶段，未来将在淘系小二工作台场景中落地。以业务作为技术的试金石和土壤，逐渐沉淀出适合淘系中后台的研发模式和开发工具。
在初期，我们会更关注开发者对新 IDE 的接受程度，核心关注留存率指标。面向长期，我们会重点关注 IDE 对研发体验和研发效率的提升度，具体的衡量指标还在制定中。
最后
做出改变、思考创新是风险很大的事情。但如果墨守成规，则很难有新的眼光和方法去突破现有体系的瓶颈。我们始终在立足于淘系的业务在思考技术方案，我们始终在坚持我们认为对的东西，大胆设想，小心论证。
Iceworks 作为 ice 下的开源项目，所有的编码和讨论均可通过 Github 仓库回溯：
- Iceworks 2.0
- Iceworks 3.0
Iceworks 4.0 版本也将会在未来合适的时机开源，欢迎关注、讨论。
封面图来自《沙巴的夕阳》。