需求规格说明书更新
-
上周写得需求规格说明书在这一周的实现过程中，实际实现起来就有一些不太合理的地方，根据实际情况我们组及时作出了调整，在每个页面的功能有增有减，具体修改如下：
-
以下仅为修改的内容
-
对3.3.1精度部分进行过修改，原因是在越往后的关卡，障碍物出现的速度会越来越快，碰撞的精度会下降。
-
补充了目录，方便查看内容
-
补充了用例示意图，之前只有表格版的，现在加上图示更清楚。
-
4.1.3界面验收标准
界面名称 界面描述 开始界面 背景图填充，有开始游戏、离开游戏、排行榜、商店等按钮 商店界面 提供不同风格的跑酷角色，供玩家进行选择跑酷 游戏界面(操作) 类似王者荣耀的两端式的按钮，在界面两侧各设置按钮来实现跑酷角色躲避障碍物的不同状态 游戏界面(游戏) 跑酷角色在当前背景图下躲避障碍物的动画 暂停界面 提供用户优势暂时的离开 加载界面 加载游戏时避免用户无聊而创建的部分 通关界面 不同风格的跑酷风格，给用户提供多样的跑酷状态 -
4.1.4功能验收标准
功能名称 操作界面 详细介绍 选择标准 商店界面 点击人物会被选择开始游戏 排行 排行界面 点击会出现最高名次 人物动作 游戏界面 通过游戏界面的按钮进行不同状态的变换 -
4.1.5游戏检验标准
功能名称 操作界面 详细介绍 人物动画 游戏界面 能够通过按钮使人物躲避障碍物实现跑酷 障碍 游戏界面 能够以一定规律进行出现 音乐 各个界面 提供游戏时音乐效果，可以手动关闭 排行 排行榜 能够查询最高成绩
-
团队编码规范
-
命名规范
-
用全英文单词命名的方式，准确地描述性质，使代码容易理解。如使用printTrace而不是PT。
-
避免命名时使用下划线。
-
采用大小写混合的方式来命名，增强命名的可读性。组成类名、变量名中的每个单词的首字母均大写，其余的小写，例如ArrayMaxHeap;方法名的第一个字母小写，其他单词的首字母大写，例如toString。
-
尽量避免使用单词缩写，对于单词过长的不得不使用缩写的情况，必须使用通用缩写方式，例如number可写为num而不是nu。并且在所有类中保持不变。
-
避免太长的命名，以少于20个字符为宜。
-
避免两个命名只是某些字母大小写不一样，其他拼写完全相同的情况，这样容易造成混淆。例如SuffixExpresion和suffixexpresion。
-
常量使用大写拼写并用下划线分隔。
-
避免使用不易理解的数字，例如：
if (state == 0) { state = 1; ... // program code }这样对于数字的理解，编码人员之间可能会有不同的理解，应改为如下:
private final static int TRUNK_IDLE = 0; private final static int TRUNK_BUSY = 1; private final static int TRUNK_UNKNOWN = -1; if (state == TRUNK_IDLE){ state = TRUNK_BUSY; ... // program code } -
数组声明的时候使用 int[] index ，而不要使用 int index[]
-
包名统一使用小写，点分隔符之间有且仅有一个自然语义的英语单词。包名统一使用单数形式，但是类名如果有复数含义，类名可以使用复数形式。
-
抽象类命名使用 Abstract 或 Base 开头； 异常类命名使用 Exception 结尾； 测试类命名以它要测试的类的名称开始，以 Test 结尾。
-
-
代码规范
-
代码中的{}不可省，在if语句和while语句中即使只有一行代码也不可省。
-
方法类型默认为是密封的。
-
对接口和复杂代码块必须进行注释，并尽量使用简洁易懂的注释代码，避免长篇大论。
-
在自定义异常时，必须使用提供的模板来创建自定义异常。
-
所有的数据类必须重载toString() 方法，返回该类有意义的内容。说明：父类如果实现了比较合理的toString() ， 子类可以继承不必再重写。例如：
public TopoNode { private String nodeName; public String toString() { return "NodeName : " + nodeName; } } -
抛出的异常必须要填写详细的描述信息,便于问题定位。例如：
throw new IOException("Writing data error! Data: " + data.toString());
-
-
OPP规约
-
当一个类有多个构造方法，或者多个同名方法，这些方法应该按顺序放置在一起
-
类内方法定义顺序依次是:公有方法或保护方法 > 私有方法 > getter/setter 方法。
-
final 可以声明类、成员变量、方法、以及本地变量，下列情况使用 final 关键字:
- 不允许被继承的类，如:String 类。
- 不允许修改引用的域对象，如:POJO 类的域变量。
- 不允许被重写的方法，如:POJO 类的 setter 方法。
- 不允许运行过程中重新赋值的局部变量。
- 避免上下文重复使用一个变量，使用 final 述可以强制重新定义一个变量，方便更好 地进行重构。
-
类成员与方法访问控制从严:
- 如果不允许外部直接通过 new 来创建对象，那么构造方法必须是 private。
- 工具类不允许有 public 或 default 构造方法。
- 类非 static 成员变量并且与子类共享，必须是 protected。
- 类非 static 成员变量并且仅在本类使用，必须是 private。
- 类 static 成员变量如果仅在本类使用，必须是 private。
- 若是 static 成员变量，必须考虑是否为 final。
- 类成员方法只供类内部调用，必须是 private。
- 类成员方法只对继承类公开，那么限制为 protected
-
使用索引访问用String的split方法得到的数组时，需做最后一个分隔符后有无内容的检查，否则会有抛出IndexOutOfBoundsException 的风险。例如：
String str = "a,b,c,,"; String[] ary = str.split(","); // 预期大于 3，结果是 3 System.out.println(ary.length); -
Object 的equals方法容易抛空指针异常，应使用常量或确定有值的对象来调用equals。应使用
“test”.equals(object);而不是object.equals(“test”);所有的相同类型的包装类对象之间值的比较，全部使用 equals 方法比较。
-
-
注释规范
-
修改代码时保持注释同步。
-
修改他人代码时要先注释对方代码，并写明修改原因，不允许随便删除他人代码。
-
发布前移除无用注释。
-
类注释
/** * @version: V1.0 * @author: fendo * @className: user * @packageName: user * @description: 这是用户类 * @data: 2017-07-28 12:20 **/ -
构造函数注释
** * @description: 构造函数 * @param: [sid, pid] */ -
方法注释
/** * @author: fendo * @methodsName: addUser * @description: 添加一个用户 * @param: xxxx * @return: String * @throws: */ -
代码块注释
/** * 实例化一个用户 * xxxxxxx */ User user=new User(); -
单句注释
User user=new User(); //实例化一个用户
-
-
选择理由
- 代码规范我们组自己想的并不完整，考虑也不周全，具体参考了网上的一些较完善的代码规范，编程规约之OOP规约
，编码规范(一)----JAVA注释规范 - 首先是与我们实际使用情况相结合的，选择的是在代码编写过程中常用的并且是有必要的。
- 第二，由于我们组是团队合作完成，所以统一且易于使用的代码规范有助于增强代码的可读性，促进小组成员的协作。
- 第三，良好的代码规范在程序出现bug时，可以方便审查代码查找错误。
- 第四，老师以前分享过一篇文章，题目是：因不写注释，码农杀了4位同事，一人情况危急...所以，我希望我们的小组成员能够健康快乐...
- 代码规范我们组自己想的并不完整，考虑也不周全，具体参考了网上的一些较完善的代码规范，编程规约之OOP规约
ER图
我们组暂未使用到数据库，下周会使用到Android Studio自带的数据库，现在对其他方面作了图。
- 主体
- 动画
项目后端架构设计
- 游戏图标是一个可爱的凸显游戏性质的图片
- 主界面包括
- 1.开始游戏按钮
- 点击进入游戏界面开始游戏
- 游戏界面有高低障碍物随机出现，玩家可以点击跳跃和俯身两个动作按钮来躲避障碍物。
- 点击进入游戏界面开始游戏
- 排行榜按钮
- 点击可以查看历史成绩，有较好的前几次成绩记录，并附有用户信息。
- 商店按钮
- 点击可以有多重人物以供玩家选择，玩家可以点击自己喜欢的人物形象来游戏，增强玩家在游戏过程中的体验感。
- 退出游戏
- 点击即可退出游戏
- 1.开始游戏按钮
团队分工
-
利用象限法确定各个核心需求的优先级
-
团队Alpha版本需要实现的功能
- Alpha版本
- 1.开始，退出，暂停按钮
- 2.游戏界面：人物，障碍物（空中、地面），跑道
- 3.障碍物出现，人物奔跑功能
- 4.商店，游戏通关/失败功能，成绩排行功能
- β版
- 1.商店选择人物功能
- 2.音乐播放功能
- Alpha版本
-
Leangoo图
-
WBS图
-
团队各个成员认领的工作，当前团队的TODOList，并在最后给出燃尽图。
-
各个成员认领的工作
- 谭鑫：动画实现
- 黄宇塘：美工
- 赵晓海：界面实现
- 方艺雯：文案
- 王禹涵：界面实现
-
ToDoList图
-
燃尽图
由于使用Github生成燃尽图的过程中，到填写网站生成图片的那一步时，码云链接无效，仅支持Github，所以上周没有生成燃尽图。这周用到的ToDoList软件有生成燃尽图功能，但制作完成后发现他不是燃尽图该有的样子，思考之后发现应该是因为前两周的是现在补的并设定为任务完成，所以在当时是没有完成的，在第一周显示的是一个任务没有完成，在第二周新增任务后显示两个任务没有完成，今天全都设定为完成任务所以下降为未完成任务为0，应该从下周开始就正常了吧。
-
总结会议
这周小组会议中主要谈论了上周工作总结和下周安排，具体情况如下：
- 上周谭鑫和赵晓海负责动画的实现并成功完成任务；黄宇塘和王禹涵负责制作背景图以及界面设计，确定了主题并且主要页面设计完成；方艺雯负责写每周总结博客以及博客中要求的一切图之类的东西。
- 下一周小组任务是实现游戏的可使用功能，能够选择人物游戏并躲避障碍物或撞上障碍物游戏失败，但没有闯关等拓展功能。其次就是界面将不断进行美化，必要时进行更换。
组员分工和工作量比例
小组分工基本不变，但相互协作，机动地变化。
| 人员 | 工作 | 占比 |
|---|---|---|
| 谭鑫 | 初步实现部分功能 | 20% |
| 黄宇塘 | 制作背景图 | 20% |
| 赵晓海 | 初步实现部分功能 | 20% |
| 方艺雯 | 写博客和需求说明书 | 20% |
| 王禹涵 | 初步实现部分功能 | 20% |