《团队做业第二周》五小福团队做业——UNO

《团队做业第二周》五小福团队做业——UNO

1、修改完善上周提交的需求规格说明书

• THE FIRST改变
• 首先：咱们组的博客无小组分工及占比，这是第一个问题，当时咱们在写博客的时候因为不少问题都在讨论筹备当中，所以，在写博客的时候并无及时的添加小组分工及占比。后来当咱们将初步工做所有完成后以后咱们在博客中补充了该内容。
  咱们小组的分工占好比下：

成员	分工	占比
郭恺	界面设计，原型设计需求分析，代码初步设计	20%
段志轩	用例图设计，代码设计和部分编写	20%
李馨雨	博客和需求说明书的撰写，功能说明图	20%
王文彬	主要几种方法代码的编写	20%
李楠	用例图设计，界面设计	20%

• THE SECOND改变

• 其次：咱们组在提交的时候并无给出用例图。由于咱们刚开始的时候并不知道用例图的做用，觉得它和咱们以前作的功能介绍图同样，后来在看了刘伟康学长的博客以后才知道用例图也须要给出，咱们小组在通过讨论以后了解到了用例图是指由参与者（Actor）、用例（Use Case），边界以及它们之间的关系构成的用于描述系统功能的视图。用例图（User Case）是外部用户（被称为参与者）所能观察到的系统功能的模型图。用例图是系统的蓝图。用例图呈现了一些参与者，一些用例，以及它们之间的关系，主要用于对系统、子系统或类的功能行为进行建模。对于了解咱们的软件有很大的做用。
  小组用例图以下：
  

• Markdown连接

• pdf连接

2、团队的编码规范

一、 标识符命名规范

1.一、命名约定

尽可能使用完整的英文描述符,采用适用于相关领域的术语;

要采用大小写混合使名字可读;尽可能少用缩写，但若是用了，要明智地使用，且在整个工程中统一；

避免使用长的名字（最好小于15个字母）；避免使用相似的名字，或者仅仅是大小写不一样的名字。

1.二、具体用例

• 包（Package）

  采用完整的英文描述符，应该都是由小写字母组成。

• 类（Class）

  采用完整的英文描述符，全部单词的第一个字母大写。 如：Card、Robot等

• 接口（Interface）

  采用完整的英文描述符来讲明接口封装，全部单词的第一个字母大写。习惯上，名字后面加上后缀 able，ible或者er，但这不是必需的。如：Contactable、Prompter。

• 组件/部件（Component）

  使用完整的英文描述来讲明组件的用途，末端应接上组件类型。 如：startButton、fileMenu

• 类变量

  字段采用完整的英文描述，第一个字母小写，任何中间单词的首字大写，如： firstName
、lastName

• 实参/参数

  同字段/属性的命名规则

public void setFirstName(String firstName)
    {
            this.firstName = firstName;
     }

• 获取成员函数

  被访问字段名的前面加上前缀get。例如：getFirstName(), getLastName().

• 设置成员函数

  被访问字段名的前面加上前缀 set。例如： setFirstName(), setLastName(),setWarpSpeed()

• 方法名

  首字母小写，如 addOrder() 不要 AddOrder()
动词在前，如 addOrder()，不要orderAdd()
动词前缀每每表达特定的含义。

• 静态常量字段（static final）

  所有采用大写字母，单词之间用下划线分隔。 MIN_BALANCE, DEFAULT_DATE

• 循环计数器

  一般采用字母 i，j，k 或者 counter 均可以接受。 i, j, k, counter

• 数组（Array）

  数组应该老是用下面的方式来命名：
byte[] buffer;

二、代码格式

2.一、 源文件编码

源文件使用utf-8编码。

2.二、行宽

行宽度不要超过130。

2.三、包的导入

删除不用的导入，尽可能不要使用整个包的导入。

2.四、代码块格式

2.4.一、缩进风格

大括号的开始要在代码块开始的下一行的行头，闭合在和代码块同一缩进的行首，例如：

public class TestStyle extends SomeClass implements AppleInter, BananaInter 
{
  public static final String THIS_IS_CONST = "CONST VALUE";

  private static void main(String[] args) 
  {
      int localVariable = 0;
  }

  public void compute(String arg) 
  {
    if (arg.length() > 0) 
    {
       System.out.println(arg);
    }

    for (int i = 0; i < 10; i++) 
    {
      System.out.println(arg);
    }
  }    
}

2.4.二、空格的使用

• 二元三元运算符两边用一个空格隔开
  以下：

a + b = c;
b - d = e;
return a == b ? 1 : 0;

  不能以下：

a+b=c;
b-d=e;
return a==b?1:0;

• 逗号语句后如不换行，紧跟一个空格
  如：call(a, b, c);
  不能如：call(a,b,c);

  2.4.三、空行的使用

  缘由：空行能够表达代码在语义上的分割，注释的做用范围，超过十行的代码若是还不用空行分割，就会增长阅读困难将相似操做。

• 使用规则：
  • 连续两行的空行表明更大的语义分割。
  • 方法之间用空行分割;
  • 域之间用空行分割;
• 示例：

order = orderDao.findOrderById(id);

//update properties
order.setUserName(userName);
order.setPrice(456);
order.setStatus(PAID);

orderService.updateTotalAmount(order);

session.saveOrUpdate(order);

上例中的空行，使注释的做用域很明显.

3.、注释规范

3.一、 注释代码规范

注释宜少而精，不宜多而滥，更不能误导。

命名达意，结构清晰，类和方法等责任明确，每每不须要，或者只须要不多注释，就可让人读懂；相反，代码混乱，再多的注释都不能弥补。因此，应当先在代码自己下功夫。不要过于详细的注释，对显而易见的代码不添加注释。

注释要和代码同步，过多的注释会成为开发的负担;注释不是用来管理代码版本的，若是有代码不要了，直接删除，不用注释掉，不然之后没人知道那段注释掉的代码该不应删除。

3.二、Java Doc

代表类、域和方法等的意义和用法等的注释，要以javadoc的方式来写。Java Doc是个类的使用者来看的，主要介绍 是什么，怎么用等信息。凡是类的使用者须要知道，都要用Java Doc 来写。非Java Doc的注释，每每是个代码的维护者看的，着重告述读者为何这样写，如何修改，注意什么问题等。 以下：

/** 个人数组帮助类
  *定义一个用于操做数组的工具类。
  *好比：获取最值，排序，折半。
  *@author 张三
  *@version V1.0
  */

具体可看博客参考

• javadoc 和 javadoc注释规范
• java文档注释--javadoc的用法

3.三、块级别注释

3.3.一、块级别注释

单行时用 //, 多行时用 /* .. */。

3.3.二、较短的代码块

用空行表示注释做用域

3.3.三、较长的代码块

用/*------ start: ------*/
和
/*-------- end: -------*/包围
如：

/*----------start: 订单处理 ------- */
//取得dao
OrderDao dao = Factory.getDao("OrderDao");

/* 查询订单 */
Order order = dao.findById(456);

//更新订单
order.setUserName("uu");
order.setPassword("pass");
order.setPrice("ddd");

orderDao.save(order);
/*----------end: 订单处理 ------- */

3.4 行内注释

行内注释用 // 写在行尾

4.选择理由

• 首先，这样方便软件维护。据统计，80％的软件开发费用在维护，规范化的代码才方便维护，下降维护成本。
• 其次， 好的编码规范可以大大加强代码的可读性，便于开发人员快速的理解新代码。任何产品都须要好的包装。咱们能够把代码自己看做是一种产品，那么按照规范编程也是对这个“产品”的包装 。
• 另外，规范化的代码也是软件质量的保证手段之一，也是软件过程可以流畅的基础。咱们每一个人必须紧紧树立这样的观念：你今天所编写的代码，会一直使用不少年，而且颇有可能被其余人维护和改进。因此，咱们必须努力写出“干净”和易读的代码。本文档适用于软件开发过程当中开发人员，主要包括编码人员、测试人员，开发人员，规范必须严格遵照，不然程序被视为不合格程序。

3、团队项目的数据库设计及相应ER图

因为咱们组的数据库较为单纯，只须要存储用户的姓名、帐号和密码以及用户在游戏中的排名和成绩，故咱们的ER图较为简单。

4、项目的后端架构设计

• 咱们小组使用Xmind实现以下：
  

• 登陆界面
  首先跳出一段咱们制做的欢迎动画，让玩家感觉到满满的游戏画面感。
  而后进入登陆界面
  登陆界面包括两个内容，注册与登陆。
  若已经注册则直接点击登陆进入游戏，若还没有注册则点击注册进入注册页面，待注册完毕后登陆进入游戏。
• 准备界面
  准备界面包括开始游戏、退出游戏、游戏介绍。
  点击开始游戏便可进入下一个界面，下一个界面包括继续上次游戏和选择游戏场规模两个选项；若选择继续上次游戏就直接进入游戏界面继续游戏，若单击选择游戏场规模就进入对游戏场的选择。一共有四个游戏场规模的选择，分别是三人场、四人场、五人场和无限场（不对牌的数量作限制）。再经过选择后进入游戏场。
• 游戏界面
  游戏界面包括如下内容：
  （1）牌类
  该内容显示你如今所拥有的全部手牌，以及不一样分类，还有其余玩家的手牌个数，牌堆剩余个数。
  （2）功能按钮类
• 一键整理按钮：能够整理你的手牌
• 选色按钮：为下一家指定颜色。
• 出牌按钮：选定你选择的牌并点击出牌，如果知足游戏规则就正常出牌，如果不知足就报错给玩家。
• 菜单栏
  • 存档：保存当前游戏，下次可在准备界面中选择继续游戏。
  • 音乐选择：能够选择打开或者关闭
  • 重来：从新开局
  • 退出：直接退回开始的主界面。

5、团队分工

成员	分工
郭恺	负责有关Android界面设计
段志轩	负责Android数据库，存放用户名、密码、用户分数
李馨雨	代码规范，后端设计，学习动画设计
王文彬	设计纸牌还有牌类完善
李楠	整理博客，学习Android数据库

【注】个别成员在没有具体工做时会进行动态分配。

• 利用象限法肯定各个核心需求的优先级：
  
• 功能介绍图（WBS）：
  

6、TODOList及燃尽图

• TODOList的项目添加
  
• 码云上的Issue：
  
• github上的Issue：
  
• 燃尽图：（仅本周任务）
  
  

7、本次分工及工做量比例

成员	我的贡献及完成度	占比
郭恺	界面的制做，学习了github完成燃尽图	20%
段志轩	经过Powerdesigner完成团队项目的数据库设计，并在随笔中提供了相应ER图。	20%
李馨雨	进行项目的后端架构设计 ，制定团队的编码规范，添加了issues	20%
王文彬	编写代码，肯定每一个子功能的工做量	20%
李楠	整理博客，利用象限法肯定各个核心需求的优先级	20%

8、本周小组会议及交互总结

  本周的共同窗习时间太少，讨论时间不够，你们作事效率比较低，总体氛围有待缓冲提升。

  在本周，咱们小组共同肯定了任务方向、制定了工做计划和任务。代码方面王文彬同窗较好的完成了本身的工做，将bug整改了；李馨雨同窗也学习了XMIND来完成了后端设计并制定了团队的编码规范，郭恺同窗也着手部分界面设计和AS学习，段志轩同窗也完成了本身负责的数据库方面，李楠同窗作了象限图、用例图和博客的整理。

  下一周咱们将投入更多时间去攻坚克难，但愿全部小伙伴们不要掉以轻心，多多作好本身份内的工做，互帮互助，努力写好小组项目的新篇章！

参考资料汇总

• [Java和Android开发学习指南]（第二版）
• 使用Github生成燃尽图
• 分而治之（Work Breakdown Structure, WBS）
• xmind新手入门教程
• ER图的绘制