软件工程第二次结对作业
| 这个作业属于哪个课程 | https://edu.cnblogs.com/campus/fzu/SE2024/ |
|---|---|
| 这个作业要求在哪里 | https://edu.cnblogs.com/campus/fzu/SE2024/homework/13281 |
| 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中，链接如下
