本篇题目是 《使用 Python 绘制统计图》，但实际要讨论的并不是如何实现，而是『技术方案的 适用性』。
只要你走上『使用技术去实现产品』的路，『技术的适用性』这个问题必然会遇到，吃一堑长一智，即使本篇谈及了这个问题，终归还是会自己遭遇到，也只有经历过后，才能真正转化为自己的能力。
『技术适用性』并非指评判某个具体的解决方案。解决方案或许有好几种，面临到底使用哪一种的选择；也有可能各种局限，只看到了其中一种方案，使用之，最后的弊端随着时间而暴露出来。
举一个例子，我曾经在完成一个产品时，全文检索使用了 ElasticSearch，主数据库是 Mongodb，然后突发奇想，放弃 Mongodb，完全使用 ElasticSearch，结果 Web 页面生成的性能急剧下降，这就出现了适用性的问题。最开始的 『突发奇想』并不是无的放矢，也考察了 ElasticSearch 非全文索引匹配的性能，应该可用；却忽略了另外一个问题， 当时一个页面的生成，特别是某几个页面，会产生很多次数据库的查询，那么性能的问题就堆积成了瓶颈。另外，ElasticSearch 的主要用途是面向全文检索，在数据结构上，也就不像常见的数据库软件那般友好了。
上面的例子中，ElasticSearch 就完全不能使用了吗？也不尽然呀。
技术适用性，是一个开放的问题。
它归根结底，是与你要付出的代价直接相关的：一个容易实现的技术方案比一个实现难度高的方案，肯定是更友好的；一个大规模应用的方案，肯定比自己拍脑袋想出来的，是更好的。
上面这句话，看起来满是保守主义的漏洞？诚然如此。
可能我们非常聪明，但是请先接受自己在技术上可能平庸的事实，特别是对于新手而言。『很聪明的我们 + 可能平庸的技术 = 很棒的产品』，这是完全成立的；所以，在技术层面，不求创新。当你接受这个限制时，在早期可以少走点歪路，往前走的路多了，想不创新，那也是不大可能的。
谈及技术适用性，归根结底，只是有两点小的提醒:
绘制统计图，还是蛮有使用场景的，将单纯的数据陈列转为视觉的形式，是更好的用户体验。
如果让你用 Python 绘制统计图，你会怎么处理？是的， 第一步肯定是在 Github、Google 或者 https://github.com/vinta/awesome-python 上找找有没有现成的 module 可用，而且像统计图这种类型的，自己从头写一个 module 比较不现实。
你会找到不少对应的 module，有历史悠久、比较丑、功能比较强的，也有新生代、好看的、使用体验不错的，但基本上你也会发现，这些 module 的依赖 (就是同时需要其它 module) 一般也比较多。生成一个图表，需要一个(图形)渲染引擎支撑， 渲染引擎可不是几行代码就能写成的，通常还要很长时间的积累。
能找到这么多 module，也说明 Python 的生态环境不错，在很多年前，可选择的会少很多，美观度也很低。简而言之，在 Python 中实现一个统计图表的绘制，还是蛮方便的。
等一下，为什么要用 Python 绘制统计图呢？用户在什么场景中使用到它？
难道因为我们只会 Python？或者因为只想用 Python 解决所有问题？
如果在网页中进行呈现，那么使用 Javascript 相关的库会更加合适；如果是桌面端的软件 (假设也是 Python 写的)，那么可以考虑通过 WebView 的方式调用 Javascript 相关的库，呈现或者生成最终的图片。
毕竟，单纯倾向于呈现的图表，Javascript 这么多年积累下来的生态，是高于 Python 的，这是一个客观的现实。
但因此而否定 Python 相关的 module 吗？
本就是两个平行世界，可能因为某个用途而短暂相遇，但归根结底，还是不同的使用场景。因此而对另外一个事物进行否定？没有必要。
本篇看过即可，也可以继续延伸，去尝试使用 Python 的方式绘制一个统计图，也可以试试如何使用 WebView 的方式绘制同样的统计图。
不论哪种尝试，都会扩展自己的视野，虽然短期来看，可能并无什么大的用处。