团队作业第二周

目录

需求规格说明书

  • 上次的《需求规格说明书》初稿有哪些不足？
  • 上周是我们敲定最终实现什么类型的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  阅读(206)  评论(0)  编辑  收藏  举报