团队作业——第二周

需求规格说明书更新

  • MarkDown

  • PDF

  • 上周写得需求规格说明书在这一周的实现过程中，实际实现起来就有一些不太合理的地方，根据实际情况我们组及时作出了调整，在每个页面的功能有增有减，具体修改如下：

  • 以下仅为修改的内容

    • 对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位同事，一人情况危急...所以，我希望我们的小组成员能够健康快乐...

ER图

我们组暂未使用到数据库，下周会使用到Android Studio自带的数据库，现在对其他方面作了图。

  • 主体
  • 动画

项目后端架构设计

  • 游戏图标是一个可爱的凸显游戏性质的图片
  • 主界面包括
    • 1.开始游戏按钮
      • 点击进入游戏界面开始游戏
        • 游戏界面有高低障碍物随机出现，玩家可以点击跳跃和俯身两个动作按钮来躲避障碍物。
    • 排行榜按钮
      • 点击可以查看历史成绩，有较好的前几次成绩记录，并附有用户信息。
    • 商店按钮
      • 点击可以有多重人物以供玩家选择，玩家可以点击自己喜欢的人物形象来游戏，增强玩家在游戏过程中的体验感。
    • 退出游戏
      • 点击即可退出游戏

团队分工

  • 参考分而治之（Work Breakdown Structure, WBS）

  • 利用象限法确定各个核心需求的优先级

  • 团队Alpha版本需要实现的功能

    • Alpha版本
      • 1.开始，退出，暂停按钮
      • 2.游戏界面：人物，障碍物（空中、地面），跑道
      • 3.障碍物出现，人物奔跑功能
      • 4.商店，游戏通关/失败功能，成绩排行功能
    • β版
      • 1.商店选择人物功能
      • 2.音乐播放功能

  • Leangoo图

  • WBS图

  • 团队各个成员认领的工作，当前团队的TODOList，并在最后给出燃尽图。

    • 各个成员认领的工作

      • 谭鑫：动画实现
      • 黄宇塘：美工
      • 赵晓海：界面实现
      • 方艺雯：文案
      • 王禹涵：界面实现

    • ToDoList图

    • 燃尽图

      由于使用Github生成燃尽图的过程中，到填写网站生成图片的那一步时，码云链接无效，仅支持Github，所以上周没有生成燃尽图。这周用到的ToDoList软件有生成燃尽图功能，但制作完成后发现他不是燃尽图该有的样子，思考之后发现应该是因为前两周的是现在补的并设定为任务完成，所以在当时是没有完成的，在第一周显示的是一个任务没有完成，在第二周新增任务后显示两个任务没有完成，今天全都设定为完成任务所以下降为未完成任务为0，应该从下周开始就正常了吧。

总结会议

这周小组会议中主要谈论了上周工作总结和下周安排，具体情况如下：

  • 上周谭鑫和赵晓海负责动画的实现并成功完成任务；黄宇塘和王禹涵负责制作背景图以及界面设计，确定了主题并且主要页面设计完成；方艺雯负责写每周总结博客以及博客中要求的一切图之类的东西。
  • 下一周小组任务是实现游戏的可使用功能，能够选择人物游戏并躲避障碍物或撞上障碍物游戏失败，但没有闯关等拓展功能。其次就是界面将不断进行美化，必要时进行更换。

组员分工和工作量比例

小组分工基本不变，但相互协作，机动地变化。

人员 工作 占比
谭鑫 初步实现部分功能 20%
黄宇塘 制作背景图 20%
赵晓海 初步实现部分功能 20%
方艺雯 写博客和需求说明书 20%
王禹涵 初步实现部分功能 20%

参考资料

posted @ 2018-12-02 19:38  FYiW  阅读(338)  评论(0)  编辑  收藏  举报