在解决了数据断点问题后，整个数据看板（数据大屏）宣告完工，耗时：开发2天（含文档学习、架构设计，及API、前端开发），优化、Bug修复1天。无论是过程，还是结果，都是相当满意，也可谓收获满满。故，在此做一番总结和感慨……
缘起
关于数据大屏，内心一直有种莫名的“恐惧感”，但又说不上为何，也许是人类本能的对于未知的恐惧。然而，实际上，在先前的工作中，已经先后使用过Highcharts、ECharts、G2等图表库，并不是什么难事。
数据大屏自从自研统计开始，便有了需求，除去最开始的文章发布统计，更多的还在于对访问数据的统计，包括PV、UV、IP、系统环境信息（浏览器、操作系统、终端设备等）、用户数（包括日活、月活等）等等。对这些沉淀的数据的挖掘、分析，对网站的运营和持续优化是有莫大的帮助的，也侧面反映了相比于赤裸裸的原始文本数据，人类更容易迷惑于光鲜亮丽的折线图、饼图、柱状图……
一旦有了需求，便有了动力，因此，前一天还在TODO List上，隔天就开始了Coding……
过程
整个开发过程分为以下几步：选型（从G2切换到ECharts）→看文档→写SQL→开发API→开发页面→改Bug。
选型
最开始使用的是G2（AntV），毕竟和AntDesign一脉相承，都出自蚂蚁，风格、体验、API、兼容性等方面会更友好些，但，最终发现，还是Too Young了。在功能完整性、API设计、文档、开发友好度等方面，还是ECharts更胜一筹，由此，干脆利落地切换到ECharts了。
文档（学习）
对于从始至终一路自学的全栈er，各种中英文文档早已经不是问题了。对于各种需求、疑问，都能快速、精准地定位到具体的文档，因此，前后花费的时间并不多。╰(￣▽￣)╭
SQL
第一个聚合查询SQL还是花了点时间，毕竟属于未知领域，需要学习。但结果还是意料之外的，基本一次成型，没有多少返工。(～￣▽￣)～
API开发
写完了SQL，API不过是查询参数的处理、查询结果数据格式的封装，自然是水到渠成，不费吹灰之力。
页面开发
重头戏，时间、精力开销的大头，难点所在。从图表使用、布局设计、样式设计，到接口调用、数据处理，可谓一大堆的问题和疑难杂症，尤其是遇到很多意料之外的细节问题。但，最后也是收获最多的地方，可谓，“不经历风雨怎么见彩虹”？
页面开发中，感触最深的便是对业务抽象能力、架构能力、基本功的考验。如何设计出灵活、优雅的架构，避免重复劳动，是一个考验码农、架构师的分水岭问题。前者只是实现功能，后者，需要考虑扩展性、健壮性、代码量，乃至性能等等方面。
至于“基本功”，无论是编程本身，还是对各种三方库的熟悉程度、文档阅读能力、问题解决能力、知识面等，都深刻影响着开发的效率和最终的产品质量。尤其在有多种解决方案时，如何快速选择并实现最合适、最优雅、性能最好的方案，反映出一个码农、架构师的真实水准。
Bug
总体上， 问题不多，多半是布局、数据处理方面的细节优化问题。
总结
这又是一次真正的“全栈”开发经历，从服务端的API到前端的图表绘制、页面展示，一个人在3天之内全部搞定，效率、结果远超想象，甚至连自己都被自己爆发的能量所惊呆——原来自己还可以做到更多、更好！
感慨
最近看到一篇文章，批判“全才”，可谓是“毒鸡汤”满满，关键是，这代表了绝大多数“专家”的看法。在他们眼里，就是搬砖、扫地的，也需要干出点“专业”精神，干一辈子，干到“专家们”可以在香车宝马豪宅里高枕无忧。他们如果想跨行、转型，“专家们”便苦口婆心地劝说、告诫“转行”的危险性、“全才”的庸俗，在他们眼里，“全才”是无能的代名词，“转行”是对现实的逃避。
可惜，“专家们”需要的只是螺丝钉，“专家们”不会告诉你，“螺丝钉”们的悲惨下场……
如果，自己遵循“专家们”的指引，那就不会先转行前端，再涉及全栈，独立开发出整个网站系统。甚至，也不会在现在再次转行、跨界。最终，自己不过是又一名碌碌无为的“码农”，徒劳一生，仅此而已。
去你的狗屁“砖家”！
