67 lines
2.4 KiB
Markdown
67 lines
2.4 KiB
Markdown
# 第一次开发记录会议内容
|
||
|
||
## 负责人：Mythwky
|
||
|
||
## 日期：2023/4/26
|
||
|
||
## 参会人：Mythwky
|
||
|
||
## 1. 确定系统框架
|
||
|
||
预计使用Flask框架作为项目的基本实现框架，使用Bootstrap Studio作为前端项目的开发工具，模板渲染引擎为Flask框架自带的jinja2。考虑到结构化的数据，预计使用MySQL进行数据的持久化存储。
|
||
|
||
## 2. 代码规范
|
||
|
||
1. 多单词组成的命名，所有单词均写完全，最有一个单词可使用前四个字母为缩写，例如`StudentInfo`（表示学生信息）
|
||
2. 类使用大驼峰命名法，例如`StudentInfo`
|
||
3. 方法使用小驼峰命名法，例如`insertInfo`
|
||
4. 属性和数据库表命名使用小写加_的方式命名例如`dormitory_building`
|
||
|
||
## 3. 补充功能
|
||
|
||
增加无序列表，展示最新通知
|
||
通知对应如下：
|
||
|
||
1. 校园最新通知（调用爬虫读取学校官网的最新通知）
|
||
2. 寝室相关的最新通知
|
||
|
||
## 4. 数据库相关
|
||
|
||
严格按照第三范式的规范设计，避免数据堆积和冗余，目前设计大纲包括宿舍楼表、宿舍楼信息表、保修工作表、员工表、宿舍信息表、用户信息表（含权限），后续补充
|
||
|
||
## 5. 使用Gitee进行版本控制
|
||
|
||
考虑到国内环境，预期使用Gitee进行版本控制，后续完成后则将发行版上传GitHub进行开源处理
|
||
|
||
## 6. 规定开发版本
|
||
|
||
考虑到是小型的管理系统，预计使用三个版本控制开发，第一版本是Dev版本，负责开发最新的功能和实现；第二版本是Release版本；第三版本是Test版本，其代码专门负责测试功能
|
||
|
||
## 7. 规定开发内容表示
|
||
|
||
使用单独的issue文档存储每一个版本的开发方向和开发需要修复的Bug
|
||
|
||
使用release+版本号.md对应该版本对应的内容和变化
|
||
|
||
规定：
|
||
|
||
1. 使用`#0001`表示开发的对应BUG和问题描述
|
||
|
||
2. 使用`@0001`表示将要实现的功能
|
||
|
||
3. 使用`&0001`表示已经完成的功能
|
||
|
||
4. 使用*斜体*标注已经完成的既定功能
|
||
|
||
5. 使用~~删除线~~标注废弃功能
|
||
|
||
6. 使用`2023/4/27/12:00`表示标记的事件的时间，只标记完成的时间
|
||
|
||
7. 使用`v0.0.1.alpha0.0.1`表示0.0.1版本的alpha测试版的第0.0.1版本
|
||
|
||
8. 非代码部分的文件夹为大驼峰命名法，例如`DevelopmentRecord`文件夹用于存放开发报告
|
||
|
||
9. 在每一次开发完成后编写和更新该version的md文档
|
||
|
||
|