軟體工程第二次作業
GitHub專案地址
https://github.com/ICP-team/102202156-102202157.git
1.具體分工
| 王黨兵 | 高濤 |
|---|---|
| 負責使用者登入，註冊 | 最佳化主頁面 |
| 專案主頁相關【新增/編輯/刪除專案】 | 開發評論功能 |
| 關鍵詞搜尋功能【支援模糊搜尋和全名搜尋】 | 開發申請相關功能 |
| 開發學院管理功能 |
2.PSP表格
| PSP2.1 | Personal Software Process Stages | 預估耗時（天） | 實際耗時（天） |
|---|---|---|---|
| Planning | 計劃 | 10天 | 8天 |
| Estimate | 估計這個任務需要多少時間 | 10天 | 8天 |
| Development | 開發 | 9天 | 7天 |
| Analysis | 需求分析 (包括學習新技術) | 5天 | 4天 |
| Design Spec | 生成設計文件 | 1天 | 1天 |
| Design Review | 設計複審 | 0.5天 | 0.3天 |
| Coding Standard | 程式碼規範 (為目前的開發制定合適的規範) | 0.3天 | 0.2天 |
| Design | 具體設計 | 1天 | 0.5天 |
| Coding | 具體編碼 | 7天 | 6天 |
| Code Review | 程式碼複審 | 1天 | 1天 |
| Test | 測試（自我測試，修改程式碼，提交修改） | 0.5天 | 0.5天 |
| Reporting | 報告 | 0.5天 | 0.5天 |
| Test Repor | 測試報告 | 0.2天 | 0.2天 |
| Size Measurement | 計算工作量 | 15天 | 8天 |
| Postmortem&Process Improvement Plan | 事後總結, 並提出過程改進計劃 | 0.2天 | 0.1天 |
| 合計 | 9天 | 9天 |
3.解題思路描述與設計實現說明
功能：
- 登入註冊
- 建立專案，申請進入專案
- 對專案可進行留言，收藏
- 看到同學分別是來自於具體某個學院
具體上述的大概功能來設計表結構
- 使用者表
- 專案表
- 留言，收藏表
- 申請記錄表
涉及到刪除功能，在設計的時候不會在資料庫中真正的進行刪除，而是進行邏輯刪除，用0和1來表示專案存在和刪除
根據網站所對應的功能，也就開始了一系列的增刪改查，比如有關建立，刪除，編輯等等
3.1我們認為重要的/有價值的程式碼片段
我們覺得有很多，比如分頁功能，中介軟體校驗等等，但一定不是業務功能的增刪改查！
就拿中介軟體校驗來說,這個是跟django的生命週期有關係的
這裡大概說一下啟動django專案，請求進來兩塊
-
django專案啟動，本質就兩件事
- 建立三個變數，分別存放中介軟體中的
process_view,process_template_response,process_exception - 將
process_request,get_response,process_response封裝到middleware_chain`中，
- 建立三個變數，分別存放中介軟體中的
-
請求進來
流程：中介軟體的執行、路由匹配、檢視函式的執行。
底層原始碼的實現是基於好幾個列表，本質就
函式的作用域 + 閉包 + 裝飾器 物件導向 + __call__方法核心是
# handler = SecurityMiddleware物件 # __call__ # process_request # get_reponse = SessionMiddleware物件 # process_response # __call__ # process_request # get_reponse = CommonMiddleware物件 # process_response # __call__ # process_request # get_reponse = KeLaMiddleware物件 # process_response關於django生命週期的流程
我之前的理解是
使用者請求進來 ——> 經過wsgi ——> 到達django程式,會先經過中介軟體,內部先按順序執行中介軟體的process_request方法，再進行路由匹配，內部將使用者請求的url和路由進行匹配，匹配成功之後再從頭執行中介軟體內部的process_view方法,然後去執行相對應的檢視函式,返回HttpResponse物件(內部封裝要返回到使用者遊覽器所有的資料),再經過中介軟體，內部執行process_response方法，將物件返回到wsgi中，處理完成遊覽器能夠認識的內容，並返還給遊覽器我現在的理解是
- 請求進來，到達wsgi元件，封裝成request物件（對原始資料進行封裝） - 原因: - 1.更加便捷的獲取請求相關的所有資料 - 2.方便django進行統一化管理(因為很多地方都需要對請求的資料進行讀取,如果封裝到request物件中就可以統一的來這讀取和設定) - 然後開始執行我們的請求,先會執行process_request - 原因: - django在啟動會把中介軟體按照倒序的順序載入,然後把裡面的process_view，process_exception,process_template_response分別搞到列表中,將process_request，process_response放到基於MIddleware的變數中，由於他裡面實現了層層的閉包又結合了物件導向中的`__call__`方法,使它完成，當請求進來走Middleware request加括號的時候，他會觸發所有的process_request，再去進行路由匹配,再去執行所有的process_view，再到檢視函式
4.成果展示
- 主頁
- 發起專案
- 申請加入專案，收藏專案
- 支援關鍵詞搜尋專案
- 檢視申請記錄
- 收藏專案
5.目錄&使用說明
目錄結構
├─assets
├─com
│ ├─form
│ ├─migrations
│ ├─static
│ │ ├─banner
│ │ ├─comment
│ │ ├─font
│ │ ├─logo
│ │ ├─others
│ │ ├─plugin
│ │ ├─q_home
│ │ └─user
│ ├─templates
│ │ ├─order
│ │ ├─others
│ │ ├─q_home
│ │ └─user
│ ├─views
│ │ └─__account__
│ │ └─__home__
│ └─__init__
│ └─__admin__
│ └─__apps__
│ └─__modesl__
│ └─__urls__
├─com_admin
│ ├─form
│ ├─migrations
│ ├─static
│ ├─templates
│ └─__init__
│ └─__admin__
│ └─__apps__
│ └─__modesl__
│ └─__urls__
├─community_management
│ └─__init__
│ └─__settings__
│ └─__urls__
│ └─__wsgi__
├─utils
│ ├─boot.py
│ ├─md5.py
│ ├─middleware.py
│ ├─models.py
│ ├─page.py
│ ├─timeTostamp.py
使用說明在專案文件中
6.測試程式碼
備註：功能程式碼邊用邊測試
片段功能自行測試，eg:md5加密 主要是對使用者傳遞的進來的密碼加密加鹽
import hashlib
def md5(string):
"""
:param string: 傳遞的引數，想要加密的資料
:return:
"""
hash_object = hashlib.md5('可以修改的字串'.encode('utf-8'))
hash_object.update(string.encode('utf-8'))
return hash_object.hexdigest()
if __name__ == '__main__':
res = md5("123456")
print(res)
7.不足
- 登入頁面使用者名稱或密碼錯誤之後，全部重寫，使用者體驗不太好！
- 不能夠個性化推薦專案/隊友【後面考慮如何實現這個演算法】
- 單純的增刪改查專案，對於類似的這種專案，用物件導向實現增刪改查，即通用化的元件，直接整合會更省時間！
後期我將會更新到gitee中，連結如下
https://gitee.com/jyppx000