DataWorks是一个提供了大数据OS能力、并以allinonebox的方式提供专业高效、安全可靠的一站式大数据智能云研发平台，提供了数据集成、数据开发、数据治理、数据安全、数据服务、应用开发、机器学习完整数据链路的产品。
痛点复杂的产品功能和技术架构
很多产品都提供了类似于IDE形态的富交互单页应用，如下图：
图1.数据开发IDE
IDE形态的产品交互类似于大多数前端工程师使用的VSCode，包含了众多的功能模块（甚至在VSCode的架构中，一切功能模块都是由插件提供），下图是一个数据开发IDE所需的最基础功能模块：
图2.IDE基础功能模块
在基础能力层面，与通用的IDE产品存在大量的能力重叠区，这也是一个IDE技术产品所需的最通用部分的功能；在此基础之上，从业务角度出发定制了上层业务能力部分，包括各种大数据计算引擎、数据开发节点（类似于VSCode中文件类型）、以及“模块”进行数据开发节点的分类和管理、看板负责提供整体数据开发节点流程的统筹视角和流程编排。
横向角度看，DataWorks拥有众多的功能模块，纵向角度看，DataWorks上单单节点就达到了额上百数量级。包括功能模块、上百数量级的节点，所有代码都糅合在一个前端工程中，加上基础的IDE功能和其它模块代码，前端工程俨然已经演化为一个单体巨石应用，随着需求不断的迭代和升级，现阶段DataWorks前端工程的体量相对于第一个版本已经不可同日而语，目前单单一次构建发布过程已经需要消耗10min+，可以预见的将来整个发布过程将会多么痛苦。
复杂的运行环境
DataWorks面临的运行环境放眼整个阿里经济体都是及其罕见的复杂，为了混合云（即专有云）这种私有独立且封闭的环境，前端无法使用cdn的能力，如何保证同一套代码能够直接复用到弹内、公有云、混合云三种形态的运行环境，这是一个极大的工程复杂度问题。
图3.复杂的运行环境
除了工程架构和复杂度，不同的运行环境对于需求迭代和发布提出了更高的管理要求，Gitlab帮助我们解决了版本之间代码冲突的问题，但是并不能解决产品发布周期上的冲突，当多个需求都需要对外发布上线，尤其在混合云需要按月为周期产出大版本，我们一边需要快速上线新feature，一边还要按照类似瀑布模型的方式将这些功能打包到专有云版本。弹内、公有云、混合云的发布节奏截然不同，众多feature按照不同的节奏要出现在不同的版本迭代中，再考虑阿里集团的熔断机制，更加剧了大家在窗口期集中发布而产生的风险。
千人千面的商业化需求
DataWorks平台虽然庞大且复杂，但是考虑到公有云和混合云环境客户的不同功能需求，我们需要提供一种足够灵活轻便，便于随时随地的功能拆散/组合以实现轻装上阵，因为挑剔的用户一贯希望能够以最少的代价购买到最合适的解决方案，DataWorks的竞争力显然也需要从灵活且具备演变能力上寻找未来。
DataWorks通过权限点的方式给功能模块单元加上开关，虽然这种方式可以解决千人千面的需求，但是也导致了前端工程中存在了大量的权限判断代码，这种方式无论是开发难度、测试成本都有较大的effect。
简陋的灰度机制
整体而言，DataWorks在灰度功能验证的时候采用的人为干预形式的灰度机制，即依赖于提前设计好一个功能开关，当我们需要验证一个功能的时候，往往是前端通过人为方式配置一个开关，筛选一部分用户进入到新设计的功能模块，经过一段时间的试跑和调整，逐步把问题解决掉，同时对用户的影响也可以控制在比较小的范围。但显然这不是一个可以反复的、随意的、自然而然的灰度机制。
人为的干预，为灰度而耗费的设计开发，使得一次灰度的成本居高不下，有些时候我们的同学甚至因为想避免麻烦，而忽视做灰度验证。当我们想通过灰度来验证的功能非常的局部，或者用户无关，工作空间无关的时候，或者我们压根不知道哪些用户会使用到某些功能的时候，灰度机制也会在传统架构下失效，即使我们想去设计，也无从下手。
紧缺的人力
DataWorks团队存在众多的产品，同时需要Cover阿里集团内外众多的数据开发需求，而前端团队也就只有10+的规模，显然这个团队规模在应付繁重的需求迭代时是捉襟见肘的，更别说在一些创新领域进行突破了，当然这也是富交互产品研发团队普遍面临的问题。
虽然在引入了React这种模块化的UI开发方式之后，在代码层面DataWorks尽量做到了代码的可重用性，但是限制于交互形态的差异，样式的迥异，业务的区别，以及研发同学自身对于业务理解上的信息不同步，以至于在推进组件化建设之后的一段时间之内都无法沉淀出能够Cover基本面的可重用业务组件。
在前后端分离，基于主流前端框架的设计模式下，相较于历史上的前后端一体设计体系下的用户体验是有提升的，然而这都是基于前端开发同学辛勤的劳作，一点点的调整样式和交互换来的成果，这里从来没有捷径可走，而我们只能寄期望于能够复用前端开发同学的研发成果，让每一次设计都不要成为只使用一次的劳动。
其他
上面列举的几点当然不能穷举DataWorks研发团队面临的众多问题，而是跟产品需求一样，上面几点已经是筛选之后显得比较痛的点，产品原则上突出要强调做减法，其实这一点在研发领域同样适用，限制于研发团队规模，我们没办法Cover所有数据开发同学的需求，那我们也反过来也希望DataWorks是一个更加开放的平台，类似于VSCode的模式，DataWorks团队重点