团队作业第二周

目录

目录

• 目录
  • • 一、修改完善上周提交的需求规格说明书
      • • 1.说明书更新原因：
        • 2.项目说明书的部分更改：
    • 二、团队的编码规范
      • • 1.标识符命名规范
          • 1.1、命名约定
          • 1.2、具体用例
        • 2.代码外观
          • 1.列宽
          • 2.换行
          • 3.缩进
          • 4.空行
        • 3.程序注释
          • 3.1、 注释代码规范
          • 3.2、块级别注释
          • 3.3 行内注释
        • 4.选择理由
    • 三、团队项目的数据库设计及相应ER图
    • 四、项目的后端架构设计
    • 五、团队分工
    • 六、
    • 七、TODOList及燃尽图
    • 八、本次分工及工作量比例
    • 九、本周小组会议及交互总结

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

1.说明书更新原因：

经过多次商讨、决定修改一部分设计。主要原因是在于布局设计及相应计算代码的考量中发现，有些设计不实用并增加设计量、使得设计同学工作量剧增，会增加程序出错的概率

2.项目说明书的部分更改：

• 3.3 性能需求
  主要面对的是广大初中生，高中生，大学生等拥有生活费，但又无法合理分配生活费支出项目的群体。通过轻松的聊天记帐方式，打破常规的记账本流水账模式，转为更人性化的根据金额进行提示，合理分配。

二、团队的编码规范

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.代码外观

1.列宽

代码列宽控制在110字符左右。

2.换行

当表达式超出或即将超出规定的列宽，遵循以下规则进行换行：

• 1.在逗号后换行
• 2.在操作符前换行
• 3.规则1优于规则2

3.缩进

每行4个空格

4.空行

为了提高代码的可阅读性，在代码中，不包含多个空行，在以下情况中使用一个空行：

• 1.方法与方法，属性与属性之间。
• 2.方法与方法之间。
• 3.方法中变量与声明语句之间。
• 4.方法中不同的逻辑块之间
• 5.方法中的返回语句与其他的语句之间。
• 6.属性与方法，属性与字段，方法与字段之间。
• 7.注释与注释的语句之间不空行，但和其他的语句空一行。

3.程序注释

3.1、 注释代码规范

注释要和代码同步，过多的注释会成为开发的负担;注释不是用来管理代码版本的，如果有代码不要了，直接删除，不用注释
先在代码本身下功夫。不要过于详细的注释，对显而易见的代码不添加注释。

3.2、块级别注释

• 1.块级别注释
  单行时用 //, 多行时用 /* .. */。
• 2.较短的代码块
  用空行表示注释作用域
• 3.较长的代码块
  用/------ start: ------/
  和
  /-------- end: -------/包围

3.3 行内注释

行内注释用 // 写在行尾

4.选择理由

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

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

四、项目的后端架构设计

五、团队分工

组员	组员分工	工作量占比
周烔	撰写博客并总结，设计燃尽图调配码云	20%
鞠明翰	学习并调用图灵机器人api，部分页面布局设计	20%
魏冰妍	学习alhartengine的使用，并设计饼状图，折线图	20%
孙铭泽	修改需求规格说明书，编写Android计算，排序代码。	20%
殷宇豪	学习数据库相关知识，并构建自己的数据库	20%

六、

• 象限法确定优先级
  
• 功能介绍图（WBS）：
  

七、TODOList及燃尽图

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

组员	组员分工	工作量占比
周烔	尝试窗口悬浮快速记账，小组任务监督及进度调控	20%
鞠明翰	完善布局文件，实现左右滑动及界面连接	20%
魏冰妍	完善统计分析功能，尝试调用聊天api	20%
孙铭泽	完善数据处理并实现调用数据库	20%
殷宇豪	完善数据库，尝试调用聊天api	20%

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

本周小组讨论忘记拍照了...因为本周恰逢单周，课程较多，作业也较多，因此小组讨论时间非常少，进度也较为缓慢。但是我们最后还是如期完成了项目的部分内容，初步的框架已经搭建好，象限图，燃尽图，用例图，项目说明书，后端设计，数据库的应用，代码的修改...小组成员都在孜孜不倦的完成属于自己的工作，总体来说虽然不如第一周那般干劲十足，但是还是燃尽了应该燃尽的一部分。