技术拆解-人才分析蜂群图
业务前端的逻辑-这部分谁来写？
能提取业务逻辑工具库么？
工作量体现在哪些地方？
这个项目也做了两周了，比预期的时间长很多。
经过分析，我们的主要工作其实就是2个(图表渲染这次用的现成的蜂群图组件，无需开发)：
- 数据预处理
- 动态配置项配置
这两天接入的困难是什么?交互太多
整个需求的不同图表，用的是一份数据，涉及很多的筛选和计算、联动交互。
根本原因-初期需求未确认：
没人对整体交互完全了解，进而导致不知道具体要做哪些数据处理。
职责分工的问题
业务后端-业务前端-可视化开发，三者的职责分工问题存在模糊的边界。比如业务数据的加工，谁都可以做，那么到底该谁来做呢？
我总结的3个决策树：
- 前端不能做的，后端做，比如这次初期的大数据量的力导向布局，前端即使用WebWorker也做不了，必须后端预处理好数据。
- 业务前端能做的，业务前端做。比如这次的筛选、分组等数据处理，业务前端完全可以做(但是我们得提供文档，供其AI辅助开发生成组件所需的数据格式)。
- 按工作量分摊：前端和后端都能做的，那么就按工作量分摊。
我们要不要做业务前端的活儿(数据处理部分)：看是不是可复用的。如果不复用，就业务前端做；如果可复用，就我们组件这边做。
优化方案
提供LLM友好的API和配置项文档
我们给到一个LLM友好的文档，给业务方，让业务方开发可以基于该文档，借助AI轻松的做数据处理。
提取工具库
这种类型的需求，搞个规范workflow(比如数据预处理-图形元素绘制-渲染)和框架，
函数提取出来，加上注释，下次给LLM用，比如工具函数(归一化、中位数等等)等。
筛选数据集
用D3+ZRender开发
可能会更快一些，因为这种业务图表，D3的数据处理和个性化定制能力更强。
坐到一起，在业务方项目上开发代码
我们可以和业务方的开发人员一起坐到一起，直接在业务方的项目上开发代码，这样可以更好地理解业务需求和数据结构，减少沟通成本。
Zod数据校验工具
可以使用Zod等数据校验工具，来确保传入的数据格式正确，减少因数据格式问题导致的错误。
技术方案拆解
布局计算
这次是全部纯前端计算好位置。
每一个组是一个单独的graph，用的蜂群图的absolute布局，自己算好位置，通过归一化 + 边距 + 比例尺计算最终的渲染坐标。
蜂群图和常规散点图的区别：一个数据点可以放多个数据。
分位线、中位线
因为这个图没真正的坐标系，是graph，所以是自己画的自定义系列，计算出【像素坐标】画的line。
数据到像素的映射-Y轴的比例尺
文本通过textContent绘制。
增量渲染
data: isVisible
漫游
前端自己维护什么delta变量?