最近做了一个文件共享的 web 应用，FileHub。
缘起
起初想学习一下Tornado这个框架，在网上看到一篇文章后，觉得挺有意思。实验室平时也确实有许多东西要共享，于是就开始着手实现。（坑 T_T 见下文）
实现
后端自然用的 Tornado 的 web 框架和模板引擎，它的异步特性还没有研究；数据库用了SQLite，这样只要有 Python 环境就可以直接跑起来；前端用了Pure+ jQuery，前者是雅虎新开源的一个纯 CSS 模块，比 Bootstrap 轻量太多，对我来说足够用了。
前端的拖拽上传、多文件上传等功能用了jQuery File Upload这个插件；后端用了nginx upload module插件。花了挺多时间在这两个插件的文档阅读和配置上。
Tornado 的文档是直接用 docstring 生成的，非常简洁清晰，看到含糊的地方可以直接跳到源代码去读，上手很快。之前一直用 Django，对比起来，Django 文档的可读性就太差了，到现在一想到读它的文档还头疼。
现在的实现版本可以无缝切换是用 nginx 还是 Tornado 来处理上传和下载。之前很满意这个功能，现在却觉得有点儿累赘（见下文）。
问题1）功能拆分
尽管是个业余小项目，但在做的过程中发现也得想点儿办法才能推动的好 。
这个应用前后做了两周，但第一周的进度很缓慢，因为并没有一份现成的设计文档，前后端也都是自己写，所以就一边写代码一边想功能点，最后发现完全抓不住重点，效率非常低。典型的表现是功能想到一半，就开始纠结变量名了……
所以这个问题还没有小到不需要拆分的程度。于是开始把功能点重新罗列一遍，排列好优先级，把每个功能将涉及到的工作都写下来，然后从上到下逐一解决，每做完一项划掉一项。这样既能有整体的把握，又能放心专注于细节的实现。
很简单，但很重要。
2）用户和需求
虽然是为了熟悉 Tornado，但做到中间还是发现，如果没有定义好要解决的问题，很多决策都没法做。要不要多文件上传？要不要打包下载？要不要用户系统？要不要在数据库中存目录结构？等等。要回答这些问题，都需要首先搞清楚，这个产品要解决什么问题。且不说这个问题是不是真实存在，以及是否有更好的解决办法。
所以想到这点还是十分忧桑的，说到底，还是希望有比“学习 Tornado ”更好的理由。
当然有了，只是不那么确信，而且好像也不是做这个东西的出发点。
文件分享可以用 FTP，百度网盘的速度也还行，为什么要用 FileHub 呢？比 FTP 用起来更方便，跑在学校机器上所以速度超快，容量也不受限，功能可以有无限的扩展性……确实，不过得交由使用者来评判了。
3）简单原则
Tornado 的上传有个硬伤，就是受制于机器本身的内存（据说啊），看到网上有人推荐 nginx 的一个插件，于是就用了这个。现在想，这真不是一个明智的选择，对于一个小团队用的工具，引入 nginx 真是一个累赘和败笔，因为安装第三方的插件需要重新编译 nginx，这个成本好像有点儿高（太麻烦）。
肯定有很好的 Python 处理大文件上传的实现，应该选择最简单的实现方式，给用户最简单的使用体验。
后续
还准备实现一些有趣的功能，不过现在已经可以正常使用了。
Github地址：https://github.com/makto/filehub
求 code review，求吐槽，Issue 里就挺好的。
最后放一张弱弱的截屏。
# 来源：Pandora
在微博上关注： 新浪, 腾讯 投稿
最新招聘
[北京] 北京 研发工程师 – 易云捷讯科技（北京）有限公司 [北京] Web开发工程师 – 易云捷讯科技（北京）有限公司 [北京] 云计算项目实施经理 – 易云捷讯科技（北京）有限公司 [上海] Python web 工程师 – 资识署投资咨询（上海）有限公司 [上海] python 研发工程师 – 晶赞科技
更多>>
生活中若没有朋友，就像生活中没有阳光一样
