团队作业第二周

目录

• 团队作业第二周
  • 修改上周的需求规格说明书
  • 团队的编码规范及选择理由
    • 编码规范
  • 数据库设计及ER图
  • 后端架构设计
  • 确定团队分工
    • 优先级及WBS图
    • TODOList及燃尽图
    • 组员分工及工作量比例
  • 参考资料

团队作业第二周

修改上周的需求规格说明书

• 第一周进行项目开发，对于项目的了解还不够深入，对于app的整体结构构造的不够完善，经过这次的后端架构，重新做出了修改
• 上周的需求规格说明书在格式上存在问题，提交上去之后图片显示以及布局都存在误差，这周找到了正确的方法进行了修改
• 上周未正确导出pdf，这周补上
• 由于临近考试周，时间比较紧张，对于一些难以实现的功能进行了删减
• markdown
• pdf

团队的编码规范及选择理由

编码规范

• 命名规则

  • 1.基本规则
    使用可以准确说明变量、字段、类、接口、包等完整的英文描述符；采用大小写混合，提高名字的可读性；采用该领域的术语；尽量少用缩写，但如果一定要使用，当使用公共缩写和习惯缩写等；避免使用相似或者仅在大小写上有区别的名字。

  • 2.包命名
    包名一律小写, 少用缩写和长名；采用以下规则：
    [基本包].[项目名].[模块名].[子模块名]...
    不得将类直接定义在基本包下，所有项目中的类、接口等都应当定义在各自的项目和模块包中。

  • 3.类或接口命名
    类或接口名是个一名词，采用大小写混合的方式，每个单词的首字母大写。尽量使你的类名简洁而富于描述。使用完整单词，避免用缩写词(除非该缩写词被更广泛使用，像URL，HTML)。

  • 4.变量命名:
    采用大小写混合的方式，第一个单词的首字母小写，其后单词的首字母大写；变量名不应以下划线或美元符号开头；尽量避免单个字符的变量名，除非是一次性的临时变量。临时变量通常被取名为i，j，k，m和n，它们一般用于整型；c，d，e，它们一般用于字符型；不采用匈牙利命名法则，对不易清楚识别出该变量类型的变量应使用类型名或类型名缩写作其后缀；组件或部件变量使用其类型名或类型名缩写作其后缀；集合类型变量，例如数组和矢量，应采用复数命名或使用表示该集合的名词做后缀。

  • 5.常量命名
    全部采用大写，单词间用下划线隔开。

  • 6．方法命名
    方法名是一个动词，采用大小写混合的方式，第一个单词的首字母小写，其后单词的首字母大写；取值类可使用get前缀，设值类可使用set前缀，判断类可使用is(has)前缀。

• 格式规范
  • 大括号的使用约定。如果是大括号内为空，则简洁地写成{}即可，不需要换行；如果是非空代码块则：
    （1） 左大括号前不换行。
    （2） 左大括号后换行。
    （3） 右大括号前换行。
    （4） 右大括号后还有else等代码则不换行；表示终 止右大括号后必须换行。
  • 左括号和后一个字符之间不出现空格；同样，右括号和前一个字符之间也不出现空格。详见第5条下方正例提示。
  • if/for/while/switch/do等保留字与左右括号之间都必须加空格。
  • 任何运算符左右必须加一个空格。
    说明：运算符包括赋值运算符=、逻辑运算符&&、加减乘除符号、三目运行符等。
  • 缩进采用4个空格，禁止使用tab字符。
    说明： 如果使用 tab 缩进，必须设置 缩进，必须设置 缩进，必须设置 缩进，必须设置 缩进，必须设置 缩进，必须设置 1个 tab 为 4个空格。 IDEA 设置 tab 为 4个空格时， 请勿勾选 Use tab character ；而在 eclipse 中，必须勾选 insert spaces for tabs 。
  • 正确用例：

public static void main(String args[]) {
        // 缩进4个空格
        String say = "hello";
        // 运算符的左右必须有一个空格
        int flag = 0;
        // 关键词if与括号之间必须有一个空格，括号内的f与左括号，0与右括号不需要空格
        if (flag == 0) {
            System.out.println(say);
        }
        // 左大括号前加空格且不换行；左大括号后换行
        if (flag == 1) {
            System.out.println("world");
            // 右大括号前换行，右大括号后有else，不用换行
        } else {
            System.out.println("ok");
            // 在右大括号后直接结束，则必须换行
        }
    }

• 注释规则

  • 类、类属性、类方法的注释必须使用Javadoc规范，使用/**内容*/格式，不得使用//xxx方式。

    说明：在IDE编辑窗口中，Javadoc方式会提示相关注释，生成Javadoc可以正确输出相应注释；在IDE中，工程调用方法时，不进入方法即可悬浮提示方法、参数、返回值的意义，提高阅读效率。
  • 所有的抽象方法（包括接口中的方法）必须要用Javadoc注释、除了返回值、参数、异常说明外，还必须指出该方法做什么事情，实现什么功能。
    说明：对子类的实现要求，或者调用注意事项，请一并说明。
  • 所有的类都必须添加创建者信息。
  • 方法内部单行注释，在被注释语句上方另起一行，使用//注释。方法内部多行注释使用/* */注释，注意与代码对齐。
  • 所有的枚举类型字段必须要有注释，说明每个数据项的用途。

  • 与其“半吊子”英文来注释，不如用中文注释把问题说清楚。专有名词与关键字保持英文原文即可。

    反例：“TCP连接超时”解释成“传输控制协议连接超时”，理解反而费脑筋。
  • 代码修改的同时，注释也要进行相应的修改，尤其是参数、返回值、异常、核心逻辑等的修改。
    说明：代码与注释更新不同步，就像路网与导航软件更新不同步一样，如果导航软件严重滞后，就失去了导航的意义。
  • 注释掉的代码尽量要配合说明，而不是简单的注释掉。
    说明：代码被注释掉有两种可能性：
    （1）后续会恢复此段代码逻辑。
    （2）永久不用。前者如果没有备注信息，难以知晓注释动机。后者建议直接删掉（代码仓库保存了历史代码）。
  • 对于注释的要求：
    第一、能够准确反应设计思想和代码逻辑；
    第二、能够描述业务含义，使别的程序员能够迅速了解到代码背后的信息。完全没有注释的大段代码对于阅读者形同天书，注释是给自己看的，即使隔很长时间，也能清晰理解当时的思路；注释也是给继任者看的，使其能够快速接替自己的工作。
  • 好的命名、代码结构是自解释的，注释力求精简准确、表达到位。避免出现注释的一个极端：过多过滥的注释，代码的逻辑一旦修改，修改注释是相当大的负担。

• 声明(Declarations)

  • 每行声明变量的数量(Number Per Line)
    推荐一行一个声明，因为这样以利于写注释。亦即，
    int level; // indentation level
int size; // size of table
    要优于
    int level, size
    不要将不同类型变量的声明放在同一行，例如：
    int foo, fooarray[]; //WRONG!
    注意：上面的例子中，在类型和标识符之间放了一个空格，另一种被允许的替代方式是使用制表符：
    int level; // indentation level
int size; // size of table
Object currentEntry; // currently selected table entry

  • 初始化(Initialization)

    尽量在声明局部变量的同时初始化。唯一不这么做的理由是变量的初始值依赖于某些先前发生的计算。

  • 布局(Placement)
    只在代码块的开始处声明变量。（一个块是指任何被包含在大括号"{"和"}"中间的代码。）不要在首次用到该变量时才声明之。这会把注意力不集中的程序员搞糊涂，同时会妨碍代码在该作用域内的可移植性。
    

  void myMethod() {
      int int1 = 0;         // beginning of method block
  
      if (condition) {
          int int2 = 0;     // beginning of "if" block
          ...
      }
  }

  该规则的一个例外是for循环的索引变量
  for (int i = 0; i < maxLoops; i++) { ... }
  避免声明的局部变量覆盖上一级声明的变量。例如，不要在内部代码块中声明相同的变量名：

  int count;
  ...
  myMethod() {
      if (condition) {
          int count = 0;     // AVOID!
          ...
      }
      ...
  }

  选择理由

• 一个软件的生命周期中，80%的花费在于维护
• 几乎没有任何一个软件，在其整个生命周期中，均由最初的开发人员来维护
• 编码规范可以改善软件的可读性，可以让程序员尽快而彻底地理解新的代
• 代码规范不仅使得开发统一，减少审查拿督，而且让代码审查有据可查，大大提高了审查效率和效果，同时代码审查也有助于代码规范的实施。
• 好的代码规范会对方法的度量、类的度量以及程序耦合性作出约束。这样不会出现需要修改一个上千行的方法或者去扩展一个没有接口的类的情况

• 规范的代码更有利于帮助我们理解开发语言理解模式理解架构，能够帮助我们快速提升开发水平

数据库设计及ER图

后端架构设计

确定团队分工

优先级及WBS图

TODOList及燃尽图

组员分工及工作量比例

学号	姓名	分工	比例
20182304	张子正	查找资源，代码编写	20%
20182306	管伟宇	整合资源，页面设计	20%
20182308	华罗晗	数据库设计，提交ER图	20%
20182313	刘尧	分配任务，后端架构，撰写博客	20%
20182327	赵天昊	代码编写，运行，测试，修改漏洞	20%

参考资料

• 使用Github生成燃尽图
• 分而治之(WBS - Work Breakdown Structure)

来源：https://www.cnblogs.com/ly20182313/p/11967636.html