一、需求分析
充值管理後臺的使用者從高到低分為三個等級，管理員，總代理和普通代理；
高階使用者能夠管理低階使用者，也能夠為低階使用者充值，低階使用者能夠向高階使用者退還充值；
同級使用者之間不可相互涉及操作，高階使用者只能對自己建立的直屬低階使用者進行操作，管理員可以對所有總代理和代理進行操作；
充值操作部分必須記錄日誌，所有使用者都可以查詢自己的充值，被充值記錄，普通代理還能查詢退分記錄

二、資料結構設計

三、開發選擇
由於開發環境選用的是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：

五、開發記錄
整個開發週期大概進行了五天搭建好了整個後臺系統。
在開發過程中遇到的問題七成來自django，三成來自前端。
Django：

• 時區的問題最好是一開始就設定好，不然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. 前端的程式碼管理和板塊沒有分類整理，亂糟糟一片；