需求规格说明书
- 上次的《需求规格说明书》初稿有哪些不足？
- 上周是我们敲定最终实现什么类型的app，并一起为之提供想法完善内容的第一周，我们大家对我们最终应该完成什么还只是有一个大概的概念，因此需求规格说明书也只是有个框架，其中的诸多内容（例如：用例图，软件和界面的验收标准）上周我们还无法补充进去，只是空有一个写着自己要向什么方向努力的框架。
- 本周对《需求规格说明书》的修改：
- 1.《需求规格说明书》中的修改在Markdown文件中的体现
Markdown
PDF - 2.绘制了该app的功能介绍图
- 3.参考其他标准的《需求规格说明书》，描写了具体用户的使用场景和用户需求分析。
团队的编码规范
1.命名规则（前五条为基本原则，后五条为具体规定）
- 一、使用可以准确说明变量、字段、类、接口、包等完整的英文描述符；
例如，采用类似 FirstName，ListAllUsers 或 CorporateCustomer 这样的名字，严禁使用汉语拼音及不相关单词命名
- 二、采用该领域的术语；
例如：图中的顶点用Vertex而非Point；
- 三、尽量少用缩写，但如果要使用，也请使用公共缩写和习惯缩写等；
例如：广度优先搜索按规范应为：BreadthFirstSearch可简写为BFS；
- 四、避免使用相似或者仅在大小写上有区别的名字。
例如：避免I和l在其中反复出现的名字。
- 五、命名应尽可能简短。
例如：如上第四条中长度超过15个字符的，可以使用公共缩写和习惯缩写。
- 六、包命名：
包名一律小写, 少用缩写和长名；
例如：package javafoundations;
- 七、类或接口命名：
类或接口名是个一名词，采用大小写混合的方式，每个单词的首字母大写,其中，规定抽象类前加Abstract异常类后加Exception。
例如：AbstractJobs/EmptyCollectionExceptions
- 八、变量命名:
采用大小写混合的方式，第一个单词的首字母小写，其后单词的首字母大写；
变量名不应以下划线或美元符号开头；
反例：$name或_name
尽量避免单个字符的变量名，除非是一次性的临时变量。临时变量通常被取名为i，j，k，m和n，它们一般用于整型；
c，d，e，它们一般用于字符型；
组件或部件变量使用其类型名或类型名缩写作其后缀；
例如：fileMenu；
集合类型变量，例如数组和矢量，应采用复数命名或使用表示该集合的名词做后缀。
- 九、常量命名：
全部采用大写，单词间用下划线隔开。
例如：MAX_NUMBER_COUNT；
- 十、方法命名：
方法名是一个动词，采用大小写混合的方式，第一个单词的首字母小写，其后单词的首字母大写；
取值类可使用get前缀，设值类可使用set前缀，判断类可使用is(has)前缀。
例如：setName;
2.代码风格
1.缩进：
程序块要采用缩进风格编写，缩进只使用TAB键，不能使用空格键（编辑器中请将TAB设置为4格）；
方法体的开始、类的定义、以及if、for、do、while、switch、case语句中的代码都要采用缩进方式；
2.对齐：
程序块的分界符左大括号"{" 和右大括号"}"都另起一行，应各独占一行并且位于同一列；
对齐只使用TAB键，不使用空格键；
不允许把多个短语句写在一行中，即一行只写一条语句；
if、for、do、while、case、switch、default等语句自占一行；
不论if、for等语句后面跟的语句数是否为1，均需要打大括号。
3.换行：
一行的长度超过80个字符需要换行，换行规则如下：
在一个逗号后面断开；
在一个操作符前面断开；
长表达式要在低优先级操作符处划分新行；
新行缩进2个TAB。
4.间隔：
类、方法及相对独立的程序块之间、变量说明之后必须加空行；
关键字之后要留空格， 象if、for、while 等关键字之后应留一个空格再跟左括号"（"， 以突出关键字；
方法名与其左括号"（"之间不要留空格, 以与关键字区别；
二元操作符如" >="、" <="、" +"、" *"、" %"、" &&"、" ||"、" <<" ," ^" 等的前后应当加空格；
一元操作符如" !"、" ~"等前后不加空格；
for语句中的表达式应该被空格分开。
5.包的导入：
整个包导入，然后根据自己的需要进行修改，切忌擅自删除包内内容；
3.注释
1.文件注释：
1.文件注释：所有的源文件都应该在开头有一个注释，其中列出文件的版权声明、文件名、功能描述以及创建、修改记录：
例如：
/**
*Copyright(C)2019-2020 Android APP Set;
*FileName:app.java
*Description:java
*History:
*版本号 作者 日期 简要操作
*1.0 王振澳 2019/12/1 Create
**/
2.类或接口注释：
采用JavaDoc文档注释，在类、接口定义之前应当对其进行注释，包括类、接口的描述、最新修改者、版本号、参考链接等；
注：JavaDoc文档注释：描述Java的类、接口、构造方法、方法、以及字段。每个文档注释都会被置于注释定界符/...*/之中，一个注释对应一个类、接口或成员。该注释应位于声明之前。文档注释的第一行(/)不需缩进，随后的文档注释每行都缩进1格(使星号纵向对齐)。
例如：
/**
*测试类（类功能的描述）
*@author wangzhenao（最新的作者）
*@version 1.0（最新版本号）
*@see Java（参考资料）
**/
3.注释格式：
单行注释格式//
多行注释格式/……/
注：单行注释上方空一行，以明确注释的作用域；
4.选择理由
- 1.提高我们的编码效率。整齐划一的代码方便我们进行复制粘贴嘛！
- 2.提高代码的可读性，使得开发人员能够更容易的理解代码。
- 3.方便团队协同工作。大家使用同一的规范，这样就消除了五花八分的书写方式，同一协调！
- 4.养成写规范代码的习惯，有助我们的成长。
团队项目的数据库设计
- 数据库设计
- ER图
项目的后端架构设计
- 主页面
- 全部习惯（尚未完成）
- 番茄钟
- 名人名言
- 百度
团队分工
| 成员 | 分工 |
|---|---|
| 吴东泽 | 博客的撰写，画各种图，协助姬旭 |
| 王振澳 | api的调用及实现 |
| 杨凯涵 | 服务器的搭建及分配任务 |
| 曹骞 | 界面设计 |
| 姬旭 | 各个按钮的调用，页面的实现 |
- 根据情况具体动态分配
象限法确定优先级
- 功能介绍图（WBS）：
TODOList及燃尽图
-
TodoList任务树
-
燃尽图
本次分工及工作量比例
| 学号 | 成员 | 分工 | 比例 |
|---|---|---|---|
| 20182312 | 吴东泽 | 博客的撰写，画各种图 | 20% |
| 20182318 | 王振澳 | api的调用及实现 | 20% |
| 20182321 | 杨凯涵 | 核心代码的实现及分配任务 | 20% |
| 20182323 | 曹骞 | 界面设计 | 20% |
| 20182334 | 姬旭 | 布局及界面美化 | 20% |
本周小组会议及交互总结
- 随着时间愈发的邻近，我们不仅讨论的时间减少了，而且积极性方面也较之前有了一定程度上的下降，频繁的碰壁，让我们对自己的方向感到迷茫，但我们正竭尽全力克服这一困难。
- 在本周中，我们组的人都顺利完成了自己的任务，杨凯涵同学为我们分配的任务，并身先士卒的搭建服务器和数据库，可惜碰壁了，但本周基本任务即代码已完成，姬旭同学完成了页面之间的调用，曹骞同学完成了页面设计，吴东泽同学完成了本周博客和其中的所有要求事项，并对他们的工作进行了一定程度的协助，王振澳同学在api方面已经成功运行，只差将其连接到我们的app中。