团队作业第二周

需求规格说明书

  • 上次的《需求规格说明书》初稿有哪些不足?
  • 上周是我们敲定最终实现什么类型的app,并一起为之提供想法完善内容的第一周,我们大家对我们最终应该完成什么还只是有一个大概的概念,因此需求规格说明书也只是有个框架,其中的诸多内容(例如:用例图,软件和界面的验收标准)上周我们还无法补充进去,只是空有一个写着自己要向什么方向努力的框架。
  • 本周对《需求规格说明书》的修改:
  • 1.《需求规格说明书》中的修改在Markdown文件中的体现
    Markdown
    PDF
  • 2.绘制了该app的功能介绍图
  • 3.参考其他标准的《需求规格说明书》,描写了具体用户的使用场景和用户需求分析。

团队的编码规范

1.命名规则(前五条为基本原则,后五条为具体规定)

  • 一、使用可以准确说明变量、字段、类、接口、包等完整的英文描述符;
例如,采用类似 FirstName,ListAllUsers 或 CorporateCustomer 这样的名字,严禁使用汉语拼音及不相关单词命名
  • 二、采用该领域的术语;
例如:图中的顶点用Vertex而非Point;
  • 三、尽量少用缩写,但如果要使用,也请使用公共缩写和习惯缩写等;
例如:广度优先搜索按规范应为:BreadthFirstSearch可简写为BFS;
  • 四、避免使用相似或者仅在大小写上有区别的名字。
例如:避免I和l在其中反复出现的名字。
  • 五、命名应尽可能简短。
例如:如上第四条中长度超过15个字符的,可以使用公共缩写和习惯缩写。
  • 六、包命名:
    包名一律小写, 少用缩写和长名;
例如:package javafoundations;
  • 七、类或接口命名:
    类或接口名是个一名词,采用大小写混合的方式,每个单词的首字母大写,其中,规定抽象类前加Abstract异常类后加Exception。
例如:AbstractJobs/EmptyCollectionExceptions 
  • 八、变量命名:
    采用大小写混合的方式,第一个单词的首字母小写,其后单词的首字母大写;
    变量名不应以下划线或美元符号开头;
反例:$name或_name

尽量避免单个字符的变量名,除非是一次性的临时变量。临时变量通常被取名为i,j,k,m和n,它们一般用于整型;
c,d,e,它们一般用于字符型;
组件或部件变量使用其类型名或类型名缩写作其后缀;

例如:fileMenu;

集合类型变量,例如数组和矢量,应采用复数命名或使用表示该集合的名词做后缀。

  • 九、常量命名:
    全部采用大写,单词间用下划线隔开。
例如:MAX_NUMBER_COUNT; 
  • 十、方法命名:
    方法名是一个动词,采用大小写混合的方式,第一个单词的首字母小写,其后单词的首字母大写;
    取值类可使用get前缀,设值类可使用set前缀,判断类可使用is(has)前缀。
例如:setName;

2.代码风格

1.缩进:
程序块要采用缩进风格编写,缩进只使用TAB键,不能使用空格键(编辑器中请将TAB设置为4格);
方法体的开始、类的定义、以及if、for、do、while、switch、case语句中的代码都要采用缩进方式;
2.对齐:
程序块的分界符左大括号"{" 和右大括号"}"都另起一行,应各独占一行并且位于同一列;
对齐只使用TAB键,不使用空格键;
不允许把多个短语句写在一行中,即一行只写一条语句;
if、for、do、while、case、switch、default等语句自占一行;
不论if、for等语句后面跟的语句数是否为1,均需要打大括号。
3.换行:
一行的长度超过80个字符需要换行,换行规则如下:
在一个逗号后面断开;
在一个操作符前面断开;
长表达式要在低优先级操作符处划分新行;
新行缩进2个TAB。
4.间隔:
类、方法及相对独立的程序块之间、变量说明之后必须加空行;
关键字之后要留空格, 象if、for、while  等关键字之后应留一个空格再跟左括号"(", 以突出关键字;
方法名与其左括号"("之间不要留空格, 以与关键字区别;
二元操作符如" >="、" <="、" +"、" *"、" %"、" &&"、" ||"、" <<" ," ^" 等的前后应当加空格;
一元操作符如" !"、" ~"等前后不加空格;
for语句中的表达式应该被空格分开。
5.包的导入:
整个包导入,然后根据自己的需要进行修改,切忌擅自删除包内内容;

3.注释

1.文件注释:
1.文件注释:所有的源文件都应该在开头有一个注释,其中列出文件的版权声明、文件名、功能描述以及创建、修改记录:

例如:
/**
 *Copyright(C)2019-2020 Android APP Set;
 *FileName:app.java
 *Description:java
 *History:
 *版本号  作者   日期        简要操作
 *1.0    王振澳  2019/12/1  Create
 **/

2.类或接口注释:
采用JavaDoc文档注释,在类、接口定义之前应当对其进行注释,包括类、接口的描述、最新修改者、版本号、参考链接等;
注:JavaDoc文档注释:描述Java的类、接口、构造方法、方法、以及字段。每个文档注释都会被置于注释定界符/...*/之中,一个注释对应一个类、接口或成员。该注释应位于声明之前。文档注释的第一行(/)不需缩进,随后的文档注释每行都缩进1格(使星号纵向对齐)。

 例如:
/**
 *测试类(类功能的描述)
 *@author wangzhenao(最新的作者)
 *@version 1.0(最新版本号)
 *@see Java(参考资料)
 **/

3.注释格式:
单行注释格式//
多行注释格式/……/
注:单行注释上方空一行,以明确注释的作用域;

4.选择理由

  • 1.提高我们的编码效率。整齐划一的代码方便我们进行复制粘贴嘛!
  • 2.提高代码的可读性,使得开发人员能够更容易的理解代码。
  • 3.方便团队协同工作。大家使用同一的规范,这样就消除了五花八分的书写方式,同一协调!
  • 4.养成写规范代码的习惯,有助我们的成长。

团队项目的数据库设计

  • 数据库设计
  • ER图

项目的后端架构设计

  • 主页面
  • 全部习惯(尚未完成)
  • 番茄钟
  • 名人名言
  • 百度

团队分工

成员 分工
吴东泽 博客的撰写,画各种图,协助姬旭
王振澳 api的调用及实现
杨凯涵 服务器的搭建及分配任务
曹骞 界面设计
姬旭 各个按钮的调用,页面的实现
  • 根据情况具体动态分配

象限法确定优先级

  • 功能介绍图(WBS):

TODOList及燃尽图

  • TodoList任务树

  • 燃尽图

本次分工及工作量比例

学号 成员 分工 比例
20182312 吴东泽 博客的撰写,画各种图 20%
20182318 王振澳 api的调用及实现 20%
20182321 杨凯涵 核心代码的实现及分配任务 20%
20182323 曹骞 界面设计 20%
20182334 姬旭 布局及界面美化 20%

本周小组会议及交互总结

  • 随着时间愈发的邻近,我们不仅讨论的时间减少了,而且积极性方面也较之前有了一定程度上的下降,频繁的碰壁,让我们对自己的方向感到迷茫,但我们正竭尽全力克服这一困难。
  • 在本周中,我们组的人都顺利完成了自己的任务,杨凯涵同学为我们分配的任务,并身先士卒的搭建服务器和数据库,可惜碰壁了,但本周基本任务即代码已完成,姬旭同学完成了页面之间的调用,曹骞同学完成了页面设计,吴东泽同学完成了本周博客和其中的所有要求事项,并对他们的工作进行了一定程度的协助,王振澳同学在api方面已经成功运行,只差将其连接到我们的app中。

参考资料

Java编码规范总结

posted on 2019-12-01 16:05  shouko  阅读(129)  评论(0编辑  收藏