Python+Django开发游戏充值管理后台
一、需求分析
充值管理后台的用户从高到低分为三个等级，管理员，总代理和普通代理；
高级用户能够管理低级用户，也能够为低级用户充值，低级用户能够向高级用户退还充值；
同级用户之间不可相互涉及操作，高级用户只能对自己创建的直属低级用户进行操作，管理员可以对所有总代理和代理进行操作；
充值操作部分必须记录日志，所有用户都可以查询自己的充值，被充值记录，普通代理还能查询退分记录
二、数据结构设计
三、开发选择
由于开发环境选用的是winserver2003，所以后台开发选用了Python+Django+Mysql 开发
前端使用了JS+HTML+AJAX+CSS
四、环境配备
Python：
选择Python 2.7.9，需要安装的第三方库有：MySQLdb，PyMySQL-0.7，APScheduler-2.0.3
Django：
一开始选择了最新的django1.10.2版本，惊喜的发现，在连接mysql数据库开始建model同步的时候总是报了一堆未知的错误，然后百度谷歌各种查，然后网上有的方案也是比较旧版的，于是忍痛选择了1.5版本的，然后惊喜的发现竟然还是同样的跟我闹，然后它的数据库同步指令跟1.7以上的也是不一样的，心累，于是最后选择了1.9版本的。很乖，不闹腾了。
Mysql：
直接下载一个免安装大众版本就行了，不挑剔，随便用
Pycharm：
超级好用的Python开发编辑器，谁用谁知道。
五、开发记录
整个开发周期大概进行了五天搭建好了整个后台系统。
在开发过程中遇到的问题七成来自django，三成来自前端。
Django：
- 如何配置静态文件，能够让前端代码能够使用到css文件或者js文件（django不同版本的配置是不同的，这个很蛋疼）1.9版本的话可以参考这边，感谢分享：https://segmentfault.com/q/1010000004286460/a-1020000004289571
- 时区的问题最好是一开始就设置好，不然django 的时间是比北京时间慢8个小时的
- 关于models的更改后同步数据库是个很头疼的问题，django采用的机制是先使用makemigrations将你定义的models类型创建为migration对象并保存到migrate文件夹当中，然后同步数据库的时候就是根据这个文件夹的变化记录来同步，如果修改了主键或者做了一些特殊的修改可能就会引发蛋疼难以解决的问题，所以我采用的最好的办法就是，删掉migrate文件夹中的文件只剩下最初的0001_initial.py文件，然后重新构建同步，数据库也最好用新的，然后完美避开那些蛋疼的问题
- django在model定义上如果你不定一个主键变量的话它是自己帮你定义一个主键变量的，这是个隐藏的坑
- django在1.8版本之后也修改了urls文件配置的方式url(r’^login_check/$’, views.loginCheck, name=”login_check”),以前是直接用字符串的方式引入方法，现在是必须填写一个可调用的函数方法
- django在向一个网页发起请求的时候底层会默认要求访问图标所以后台会报错Not Found：favicon.ico；关于这个问题的解决网上给的也都是旧版本的方法，这里给出1.9的标准解答方法：在静态文件夹static中新建一个images放置一个ico文件然后在urls中配置一条 url(r’^favicon.ico$’, RedirectView.as_view, {‘url’: ‘/static/images/favicon.ico’})
前端：
- 以前不会用JQuery和Ajax的时候，数据的传递基本都是靠表单的跳转，然后一堆乱七八糟的页面，一堆没有意义的参数传递，简直是mdzz
- 关于登陆注册的验证上面，现在有很多现成的工具或者插件可以使用，没必要自己造轮子，比如jQuery的 Validate插件就是一个很好的表单验证工具，或者是利用Html5中的表单提交前执行事件去做验证操作
- 在遇到一些特殊的功能，比如输入日期，数字之类的，多去看看有没有现成的工具，就会发现HTML5早就有现成的输入框类型可以用了，就不用自己再用正则表达来去验证用户的输入，多此一举。
- 在一个复杂的主页面有多个功能的ajax请求，我没有用一个公共函数或者回调，导致了前端的代码很冗长，这是一个坑点，不过现在也懒得去填了以后慎挖坑。
六：系统功能展示：
七：不足之处：
1. 在Python后台进行玩家的一些扣费处理时没有使用Python的with事务操作，虽然有日志记录，但是还是需要保证一套操作的完整运行；
2. 没有使用models的多对多和一对多的数据关系进行处理，更高效得管理用户数据；
3. 前端的代码管理和板块没有分类整理，乱糟糟一片；