优酷项目
从需求角度分析我们的架构
我们的需求分为两个部分，一部分针对普通用户，一部分需求针对管理员用户。
我们的管理员需要负责完成电影的上传和对公告的发布，也就是对资源的上传。
我们的普通用户需要完成对电影的下载，以及对信息的查看，也就是对数据的获取。
我们分为两个界面，两个输入层，也就是和用户直接交互的界面。
针对不是双端的项目，我们知道，我们还有接口层和数据处理层，这里，这两层应该放到我们的服务端去执行，因为数据都是放在服务器上面的，所以我们的interface搬到了服务端。
双端的common是对功能的复用，比如我这里需要这个功能，那里也需要，那么，我可以把这个功能写到common。
Setting是我们对参数的复用，与common的道理相同。
在服务器端，我们还有common_interface，但是其实理解上也是一样的道理，是对我们管理员和普通用户共有功能的复用。
这样，我们项目的大概框架就出来了。
我们这里需要用到数据库，所以我们封装了orm，就我个人而言，我觉得难点在于对空间的产生那里，这里是很多人不理解的地方，我觉得在理解的过程中，可以多打印下看看参数到底是什么，或许就会从中受到更多的启发。
这里说一下整个项目需要注意的地方：
- 在封装orm和框架的过程中，一定要慢，再慢，更更慢，为什么这么说？我个人在封装框架的过程中，会仔细写每一步，每一个函数写完我会整体再检查一遍，整个逻辑写完，我会再检查一遍，这不是浪费时间，这恰恰是节约时间，其中的道理我相信每个人也各有体会。
- 在数据通信中，一定要知道自己传的是什么，需要实现什么样的功能，才能在双端写起来更加的得心应手，俗话说得好，一剑在手，万夫莫敌，连自己手中的剑在哪都不知道，自然会出现各种bug，也就是说，写一个功能前可以短暂的先思考下。
- 遇到bug，一定要先去看报错信息，这能让你快速的确定错误在哪，平日里练习就可以总结报错类型。
这里说一下用到的知识点：socket模块，time模块，hashlib模块，pymysql模块，struct模块，concurent模块中futures里面的线程池，orm的封装，装饰器，session的概念理解，threading中的Lock线程锁。
只要能理出来整个架构的逻辑，再攻克每一个技术点，我相信，都可以很好的完成优酷项目。
