团队做业——第二周

需求规格说明书更新

• 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注释规范