团队作业第二周

团队作业第二周

目录

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

• 二、团队的编码规范

  • 1.标识符命名规范
  • 2.代码格式
  • 3.注释规范
  • 4.选择理由

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

• 四、项目的后端架构设计

• 五、团队分工

• 六、象限法确定优先级

• 七、TODOList及燃尽图

• 八、本次分工及工作量比例

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

• 参考资料汇总

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

• 改变一：没有提交用例图，因为是第一周并不知道用例图的作用，以为它和之前做的功能介绍图一样，后来在看了1723班学长的博客之后才知道用例图也需要给出，我们小组了解到了用例图是指由参与者（Actor）、用例（Use Case），边界以及它们之间的关系构成的用于描述系统功能的视图。用例图（User Case）是外部用户（被称为参与者）所能观察到的系统功能的模型图。用例图是系统的蓝图。用例图呈现了一些参与者，一些用例，以及它们之间的关系，主要用于对系统、子系统或类的功能行为进行建模。对于了解我们的软件有很大的作用。
  

• 改变二：界面设计和说明不太好，因为上周的界面设计没有设计完整，只设计了一部分，所以也不好说明，这次改变是更加完善一下。

• 改变三：删除了一些功能，以为时间紧急，难度较大，无法实现。

• 需求规格说明书链接
  Markdown链接
  pdf链接

二、团队的编码规范

1.标识符命名规范

1.1、命名约定

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

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

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

1.2、具体用例

• 包（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.代码格式

2.1、 源文件编码

源文件使用utf-8编码。

2.2、行宽

行宽度不要超过130。

2.3、包的导入

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

2.4、代码块格式

2.4.1、缩进风格

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

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.2、空格的使用

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

  如下：

   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.3、空行的使用

  原因：空行可以表达代码在语义上的分割，注释的作用范围，超过十行的代码如果还不用空行分割，就会增加阅读困难将类似操作。

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

  order = orderDao.findOrderById(id);

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

  orderService.updateTotalAmount(order);

  session.saveOrUpdate(order);

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

3.注释规范

3.1、 注释代码规范

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

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

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

3.2、Java Doc

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

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

• 具体可看博客参考
  • javadoc 和 javadoc注释规范
  • java文档注释--javadoc的用法

3.3、块级别注释

3.3.1、块级别注释

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

3.3.2、较短的代码块

用空行表示注释作用域

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％的软件开发费用在维护，规范化的代码才方便维护，降低维护成本。
• 其次， 好的编码规范能够大大增强代码的可读性，便于开发人员快速的理解新代码。任何产品都需要好的包装。我们可以把代码本身看作是一种产品，那么按照规范编程也是对这个“产品”的包装 。
• 另外，规范化的代码也是软件质量的保证手段之一，也是软件过程能够流畅的基础。我们每个人必须牢牢树立这样的观念：你今天所编写的代码，会一直使用很多年，并且很有可能被其他人维护和改进。所以，我们必须努力写出“干净”和易读的代码。本文档适用于软件开发过程中开发人员，主要包括编码人员、测试人员，开发人员，规范必须严格遵守，否则程序被视为不合格程序。

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

• 由于我们组的数据库较为单纯，只需要存储时间，地点，重要程度和内容。故我们的ER图较为简单。
  使用PowerDesigner画ER图详细教程

四、项目的后端架构设计

五、团队分工

成员	分工
袁源	负责Android数据库，存放待办集的内容
彭淼迪	编写所需java代码,并辅助他人完成任务
王美皓	待办集的页面布局
李一卓	负责有关Android后端界面设计和部分页面布局
钱佳禹	整理博客，代码规范、搜集代码、燃尽图以及一部分代码的编写。
【注】个别成员在没有具体工作时会进行动态分配。

六、象限法确定优先级

• 功能介绍图（WBS）：
  

七、TODOList及燃尽图

• TODOList的项目添加
  

• 码云上的Issue：
  

• 燃尽图：（仅本周任务）
  

八、本次分工及工作量比例

成员	分工	占比
袁源	学习Widget,编写Andoid代码	20%
彭淼迪	学习Widget,编写Java代码	20%
王美皓	页面布局设计	20%
李一卓	实用墨刀实现后端架构设计、通过Powerdesigner完成团队项目的数据库设计，并在随笔中提供了相应ER图。	20%
钱佳禹	撰写博客，完成燃尽图，利用象限法确定各个核心需求的优先级	20%

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

• 本周的共同学习时间太少，讨论时间不够，大家做事效率比较低，但是我们永不言败，以积极的心态去面对它。
• 在本周，我们小组共同确定了任务方向、制定了工作计划和任务。代码方面彭淼迪同学出色的完成了自己的工作，将bug整改了；李一卓同学也学习墨刀来完成了后端设计并进行部分页面布局的设计，王美皓同学也着手分界面设计和Andorid Studio的学习，袁源同学也出色完成了自己负责的数据库方面，钱佳禹同学做了象限图、用例图和博客的整理以及代码的搜集。

参考资料汇总

• [Java和Android开发学习指南]（第二版）
• 使用Github生成燃尽图
• 分而治之（Work Breakdown Structure, WBS）
• 使用PowerDesigner画ER图详细教程