团队作业第二周

目录

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

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%

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

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

posted @ 2019-12-01 17:52  tursws  阅读(115)  评论(0编辑  收藏