团队作业——第二周

需求规格说明书更新

• 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%

参考资料

• 使用Github生成燃尽图
• 分而治之（Work Breakdown Structure, WBS）
• ToDoList使用介绍
• ER图的绘制
• 编程规约之OOP规约
• 编码规范(一)----JAVA注释规范