当产品和设计在讨论改版的时候，我们在讨论什么

| 导语 腾讯扣叮是面向6-18岁的青少年推出的编程教育平台，其中编程工具有：创意，AI、Python、硬件、3D、游戏、C等实验室。每个实验室的底层差不多，都是由其中blockly、paint、sound-editor、assetslib这几个组成，在结合各实验室业务自身组件拼装完成。所有这些我们都有一个最基础的eui组件库作为业务支撑。

随着业务的不断深入，我们设计也对不同品类的IDE工具进行细分，能让用户对不同工具的感官体验舒畅、愉悦。所以这次先从使用频率最高的创意实验室入手，探索一些模块优化，视觉品牌升级的小成本改版。

我们先来看看改版前后的设计稿对比

改版前

改版后

本次小成本改版对我们工作量的影响：

1、框架保持不变（暗自窃喜）

2、模块样式整体刷新，也就是说我们要对着每个组件逐个刷新一遍（工作量最大部分）

遇到的问题

1、前面说了，我们的IDE页面是由多个外部组件和自身业务组件组成，这对于我们整体调试来说是个麻烦事。

比如A组件需发布到tnpm上，然后在工程install下才能看到效果。虽然每个组件都可以单独预览效果，但是整体调试是割裂的。

2、IDE也经历了大大小小各种功能视觉的迭代，看似简单页面的背后，有着复杂的逻辑功能组件在里面。由于历史原因，每个组件也都有各自的不统一的variable.less。里面冗余的样式好多。

3、这个实验室里面还有一些很深的控件，有些时候可能设计师都忘了，那设计稿get不到，我们怎么去刷新样式呢？

解决方案

首先设计在改版跟产品定稿前，我们先梳理好这个ide的框架组件构成。

框架布局没有任何影响，主要是组件。如下图

内部的业务组件有10来个，外部引用tnpm包上的组件有这几个。其中，blockly、paint、sound-editor是第三方开源的工具。改起来难度较大。而且样式都是CSS Modules方式，我们在业务项目中也不好覆盖，就算重新用全局作用域覆盖了。对以后扩展到其他实验室也还是要复制代码一遍。

所以干脆就在tnpm项目里对样式进行修改。调试用npm link方式直接映射本地文件，这样不用改一次发个包看效果。

这里又引出一个问题，比如A组件，我只想在创意实验室用白色系皮肤，在3d实验室用黑色系。那怎办呢？

目前还是用在业务项目中覆盖样式的写法。接下来其他实验室改版优化，参考ant design，尝试用less提供的modifyVars方式覆盖变量的方法！

其次快刀斩乱麻，长痛不如短痛。从创意实验室开始，基于EUI的variable.less，针对该业务重新梳理统一的variable.less。使它更适用于当前业务。

得益于设计师的严谨和专业，我们前期定制的规范都能遵循。每个细微的状态都标注的清清楚楚。所有的控件都是统一的，有法可循的，就算很多隐性的状态组件设计稿上没体现，只要遵循这个方法原则，我们替换好tokens值后，也会刷新。

所以我们在定义Design Tokens就很清晰。

颜色遵循规则：

控件状态：

遵循这样的规范，我们后续对其他实验室的皮肤定制改版也迎刃而解。

最后总结：

• 本次改版只是涉及到样式的小范围刷新，一定要跟设计定好统一规则。否则这套variable.lees就越堆越多。
• 对于外部组件的定制化，后续在业务项目中用less提供的modifyVars方式覆盖其变量达到定制换肤功能。
• 外部组件的样式全局命名有冲突的风险，后续考虑使用css modules的方式。

无处不在的辛普森悖论

从0到1实现一款轻量级大数据分析系统

腾讯的组织能力是什么