原标题：10 Years of Open-Source Visualization-Did I learn anything from D3.js? Let’s see…
原作者：Mike Bostock
编译：康楷数据开发与设计部
按：
D3.js 全称为Data-Driven Documents，是一个数据可视化JS库，兼容W3C标准。2009年斯坦福大学可视化团队（现为华盛顿大学交互数据实验室，效力微软）利用先前开发Prefuse和Flare库的经验，使用JS开发SVG可视化图形库Protovis。2011年，Protovis停止开发，Mike Bostock等人发布全新的数据可视化D3.js库，注重Web标准同时丰富功能。2016年，Mike Bostock和Melody Meckfessel创办Observable网站，在线编写可视化JS脚本，实时输出图像结果。后期不断加深该网站的社区属性。
时值D3.js问世十周年（2011年~2021年）, Mike Bostock在Observable撰文纪念，谈论感想体会。
译文有删改。
以下为正文：
D3-1.0发布十年之际，我撰写这篇经验贴。不求面面俱到，但求交流心得，继往开来。希望读者朋友们有所启发。
1、以教学扩影响
开发工具时，你很容易忽略自己相对于用户的知识储备。对你来说显而易见的东西，对于别人来说可能完全陌生。你的目标是授人以渔，不能闭门造车！自己怎么想不重要，别人怎么用才重要！
想拓展受众，就必须以教学为中心，文档、教程、案例、视频、推文等等。一对一辅导可以让你系统阐述个人所学，与对方产生共鸣，收获灵感，精进教学（见2），但随着受众人数激增，被动式的“教学素材库”最为有效。上课一天教一百人，撰文一篇教几万人。Rich Harris和Dan Abramov的教学风格出色，令人羡慕，也启发了我。
所有教学文档中，案例是最有效的。我长期支持案例教学，Observable网站及其前身bl.ocks.org都是以案例为主帮助人们速成。案例激发灵感、展示技巧、轻松入门。鉴于人类在观察和模仿中学习最快，案例是教学的不二法门。
当然，案例太强也会过犹不及：虽可跨过复杂的api技术文档，但养成复制粘贴的陋习。难道说D3本身并不成功，只是因为案例底子厚？（摊手）身为作者，我也记不住d3.stack的用法，和大家一样去stack案例中复制粘贴。有了案例的帮助，工具设计上的瑕疵被忽略了，但为了那些刨根问底的用户，还是要保证工具设计逻辑通顺。从呈现结果倒推，而非数据正推的工作流程，会招致错误（见5）。案例也有局限性：情境过于具体，不能举一反三。
2、以支持促研发
开发者和用户对工具的理解有分歧，弥合分歧的手段就是技术支持。在Stack Overflow（或GitHub、Twitter、Slack等平台）答疑解惑不仅是积德行善，同样是学习的机会，发现痛点，了解需求。一次解答只能帮一人不假，但能启发你撰写一篇教程、一个案例，避免他人踩坑。这就是成功工具的隐含优势：用户们不计其数的想法和批评，被开发者转化成为产品迭代和帮助文档——这些东西不会凭空产生。
局限性依然存在，你帮不了所有人 。你不能让所有人心满意足，因为工具只是其生活一小部分。别过于专注解决分歧，非建设性建议不用理会。我不赞同GitHub和其他平台默认开启issue，这释放了错误信号：无偿开发者有义务立刻、礼貌、彻底解决一切问题。诚然，我可以关闭issue，但社区应该重新考虑规则制定，缓解开发者的疲劳。
3、警惕花里胡哨：交互、动画及其他炫技的代价
这些东西自有其功用，但听我一句劝。交互和动画令人赞叹，对外行人效果尤甚。一旦明白这点，你会无所不用、能炫就炫，忘记其弊端。比如，无谓地增加了复杂性，用户没看到有用的信息。高难功能喧宾夺主，无聊但重要的呈现数据规律被忽视了。
我不是一棍子打死，我自己也没做到。但陷阱真实存在。首先把精力放在静态图上，用户看见啥就是啥。别在web技术上花太多精力，无需担心可视化过于朴素：能呈现规律才是关键，而不是装裱。
那么交互用在哪呢？主要用于探究型可视化（见4），Gregor Aisch的文章《捍卫交互图表》也有所阐释。
4、可视化光谱：探究型→解释型
数据可视化目标各异。探究型侧重呈现数据规律、形成见解，解释型侧重阐释已有信息。设计可视化图表时要目的明确。
探究型追求构建速度：最快能多快出图？如果是自用就省事了，直接上图。否则就必须提供解释型图表解释来龙去脉，优秀的解释型图表应当主旨明确、表达充分。解释型可以包含探究型，让用户知道自己到哪一步了，但不能喧宾夺主。别让用户费力摸索数据规律，你作为编者要主动呈现。
5、大多数情况下，可视化80%工作是处理数据
可视化是分析的终点、数据的视觉展现，老少咸宜，赏心悦目，但有时位置摆太高了。要产生可视化结果，必须先找数据、洗数据、转置、关联、建模等等。数据处理是理解数据的根本，虽时常被讽以“清洁工”，但至关重要。（参见Leigh Dodds文章。）只要数据干净完整，可视化反而简单（在第三条前提下）。因此D3库中，我用的最多的是d3-array和d3-dsv。我也乐见诸如tidy.js和Arquero这样的新JS数据工具出现。Hadley Wickham的“清洁数据”范式是无价的。
6、视觉形式不拘一格
饼图树图如一般，视觉形式无优劣。信息传达是核心，具体问题具体看。
如果复制粘贴的案例套不进去（见1），就创造专门的呈现形式确保效果。在一种图上花的时间越少，能尝试的种类就越多，最终效果也越好。Observable帮助用户快速获取数据，比如一键替换文件，无需克隆直接改代码等。当然，如果数据结构不兼容，仍需很多处理工作（见5）。况且D3专司解释型可视化，相较于Vega-Lite这种探究型可视化还要麻烦一些。要想降低代码量，可以多套用几个案例试试，看哪个最适用。我们努力让简化Observable可视化出图，新功能不久上线，请期待。
7、10%代码产生90%bug
数是我编的，差不多就这感觉：某些代码更容易错。倒不是这些代码质量低，而是其功能实现困难或目标不明确。对D3来说，交互是bug重灾区：d3-zoom、d3-drag和d3-brush。即便挨个测试，面对各种异步事件也很难纠错。交互都是模棱两可的：你在点击？还是拖动？平移？选择？还是双击？雪上加霜的是浏览器变化，单方面“破坏网页”，比如Chrome被动事件监听器。
建议是提前明确需求，可以省去大量麻烦。比如，如果能用Observable的输入和数据流控件写界面，就不用低级事件监听器，这样能剩下很多精力。
8、网络喷子令人沮丧
不管你搞得多好，只要作品放到网上，就会有人恶语中伤。也不是故意的吧，但这不重要。我对D3深感自豪，但很多人发推特喷，这些推文我都攒下来了，这是我的个人方式，别见怪。（我不会分享这些推文）
我不是玩不起，我完全理解使用工具时的无助感——你只想做个小图表，却不得不学习额外一百万个知识点。工具开发本来就是很主观随意的。问题还是在于网络。过去你跟朋友同事抱怨D3垃圾，他们会帮你处理问题，也理解你是在发泄情绪。但通过网络，我也听到了这些抱怨，但我可不认识你。不烦吗？我开发的初衷是分享使用者的快乐，可现在只有沮丧和抱怨，我这是何必？我不如躺下看会儿视频，何必遭罪？
所以麻烦某些人在喷之前，先掂量掂量自己要说的话。如果都是于事无补的垃圾话，就别发了。不如出点力，写PR、写文档，为开源做贡献。
9、不要独来独往
为防止你把个人心理健康扔给喷子的海洋（见8），你必须有一个团结友爱的小团体。换言之，找一支可以检验、反馈、指导你的团队（或者社区）。这对除我以外所有人都是显见的好处——Mike，交朋友有好处——即便现在陌生人之间也可以互助，我仍然要重复这句话。我很高兴Observable可以通过社区虚拟空间进行协作，不是为了在推特上显摆，而是实打实地协作探索数据规律。
10、保持好心情
我最早措辞是“放松”，但感觉太假。我是最不放松的，但我希望我能放松。这是性格问题，我努力反思自己生活工作中的兴趣所在，花时间去做喜欢的事。然而知易行难！你去做喜欢的事，失败就不会那么痛苦——兴趣是最好的动力。我喜欢开发工具。虽然前途未卜，但我喜欢解决难题和摆弄抽象概念的过程，而且我喜欢看到别人使用我做的工具。公开演讲虽然效果很好，于我有益，但抛头露面还是会让我焦虑。要是你因为我没有新演讲而失望，就当我在埋头开发新工具吧。
特此声明：对本文的引述、引用和节选转载行为，依照《中华人民共和国著作权法》须注明出处；对本文全文转载或引用的，除注明出处以外，须取得我公司的书面授权。
