一、建立团队项目 的码云git代码库：
地址为：https://gitee.com/ZZUOldUncle/rich-app
二、讨论制定团队的编码规范，讨论之前和讨论之后，队员阅读《构建之法》第四章内容，并讨论总结。将代码规范和编码原则发布。
代码规范：
（一）代码风格规范
4个空格的缩进
每个{}独占一行
不要把多个变量定义在一行
（二）代码设计规范
函数：只做一件事，并且要做好单一出口
不要在构造函数中做复杂的操作，简单初始化所有的数据成员即可
（三）命名规范：主要采用驼峰命名法
1、代码中的命名均不能以下划线或美元符号开始，也不能以下划线或美元符号结束。
反例：_name / __name / $Object / name_ / name$ / Object$
2. 代码中的命名严禁使用拼音与英文混合的方式，更不允许直接使用中文的方式。
正例：alibaba / taobao / youku / hangzhou 等国际通用的名称，可视同英文。
反例：DaZhePromotion [打折] / getPingfenByName() [评分] / int 某变量 = 3 3
3、类名使用 UpperCamelCase 风格，必须遵从驼峰形式，但以下情形例外：DO / BO / DTO / VO / AO 正例：MarcoPolo / UserDO / XmlService / TcpUdpDeal / TaPromotion
反例：macroPolo / UserDo / XMLService / TCPUDPDeal / TAPromotion
4、方法名、参数名、成员变量、局部变量都统一使用 lowerCamelCase 风格，必须遵从 驼峰形式。
正例： localValue / getHttpMessage() / inputUserId
5、常量命名全部大写，单词间用下划线隔开，力求语义表达完整清楚，不要嫌名字长。
正例：MAX_STOCK_COUNT
反例：MAX_COUNT
6、中括号是数组类型的一部分，数组定义如下：String[] args;
反例：使用 String args[]的方式来定义
7、包名统一使用小写，点分隔符之间有且仅有一个自然语义的英语单词。包名统一使用 单数形式，但是类名如果有复数含义，类名可以使用复数形式。
正例： 应用工具类包名为 com.alibaba.open.util、类名为 MessageUtils
8、杜绝完全不规范的缩写，避免望文不知义。
反例：AbstractClass“缩写”命名成 AbsClass；condition“缩写”命名成 condi，此类随 意缩写严重降低了代码的可阅读性。
9、如果模块、接口、类、方法使用了设计模式，在命名时体现出具体模式。 说明：将设计模式体现在名字中，有利于阅读者快速理解架构设计理念。
正例：public class OrderFactory; public class LoginProxy; public class ResourceObserver;
10、接口类中的方法和属性不要加任何修饰符号（public 也不要加），保持代码的简洁 性，并加上有效的 Javadoc 注释。尽量不要在接口里定义变量，如果一定要定义变量，肯定是 与接口方法相关，并且是整个应用的基础常量。
正例：接口方法签名：void f(); 接口基础常量表示：String COMPANY = "alibaba";
反例：接口方法定义：public abstract void f(); 说明：JDK8 中接口允许有默认实现，那么这个 default 方法，是对所有实现类都有价值的默 认实现。
（四）常量定义
1. 不允许任何未经定义的常量直接出现在代码中。
反例：String key = "Id#taobao_" + tradeId; cache.put(key, value);
2. long 或者 Long 初始赋值时，使用大写的 L，不能是小写的 l，小写容易跟数字 1 混淆，造成误解。
3. 不要使用一个常量类维护所有常量，按常量功能进行归类，分开维护。 说明：大而全的常量类，非得使用查找功能才能定位到修改的常量，不利于理解和维护。
正例：缓存相关常量放在类 CacheConsts 下；系统配置相关常量放在类 ConfigConsts 下。
4. 如果变量值仅在一个范围内变化，且带有名称之外的延伸属性，定义为枚举类。下面 正例中的数字就是延伸信息，表示星期几。
正例：public Enum { MONDAY(1), TUESDAY(2), WEDNESDAY(3), THURSDAY(4), FRIDAY(5), SATURDAY(6), SUNDAY(7);}
（五）代码格式
1. 大括号的使用约定。如果是大括号内为空，则简洁地写成{}即可，不需要换行；如果 是非空代码块则：
1） 左大括号前不换行。
2） 左大括号后换行。
3） 右大括号前换行。
4） 右大括号后还有 else 等代码则不换行；表示终止的右大括号后必须换行。
2. 左小括号和字符之间不出现空格；同样，右小括号和字符之间也不出现空格。
反例：if (空格 a == b 空格)
3. if/for/while/switch/do 等保留字与括号之间都必须加空格。
4. 任何二目、三目运算符的左右两边都需要加一个空格。 说明：运算符包括赋值运算符=、逻辑运算符&&、加减乘除符号等。
5. 采用 4 个空格缩进，禁止使用 tab 字符。 说明：如果使用 tab 缩进，必须设置 1 个 tab 为 4 个空格。IDEA 设置 tab 为 4 个空格时， 请勿勾选 Use tab character；而在 eclipse 中，必须勾选 insert spaces for tabs。
6. 注释的双斜线与注释内容之间有且仅有一个空格。
正例：// 注释内容，注意在//和注释内容之间有一个空格。
7. 单行字符数限制不超过 120 个，超出需要换行，换行时遵循如下原则：
1） 第二行相对第一行缩进 4 个空格，从第三行开始，不再继续缩进.
2） 运算符与下文一起换行。
3） 方法调用的点符号与下文一起换行。
4） 方法调用时，多个参数，需要换行时，在逗号后进行。
5） 在括号前不要换行，见反例。 正例： StringBuffer sb = new StringBuffer(); // 超过 120 个字符的情况下，换行缩进 4 个空格，点号和方法名称一起换行 sb.append("zi").append("xin")... .append("huang")... .append("huang")... .append("huang");
反例： StringBuffer sb = new StringBuffer(); // 超过 120 个字符的情况下，不要在括号前换行 sb.append("zi").append("xin")...append ("huang"); // 参数很多的方法调用可能超过 120 个字符，不要在逗号前换行 method(args1, args2, args3, ... , argsX);
8. 方法参数在定义和传入时，多个参数逗号后边必须加空格。
正例：下例中实参的"a",后边必须要有一个空格。 method("a", "b", "c");
9. 没有必要增加若干空格来使某一行的字符与上一行对应位置的字符对齐。
正例： int a = 3; long b = 4L; float c = 5F; StringBuffer sb = new StringBuffer(); 说明：增加 sb 这个变量，如果需要对齐，则给 a、b、c 都要增加几个空格，在变量比较多的 情况下，是一种累赘的事情。
10. 方法体内的执行语句组、变量的定义语句组、不同的业务逻辑之间或者不同的语义 之间插入一个空行。相同业务逻辑和语义之间不需要插入空行。 说明：没有必要插入多个空行进行隔开。
（六）注释规约
1. 类、类属性、类方法的注释必须使用 Javadoc 规范，使用/**内容*/格式，不得使用 // xxx 方式。 说明：在 IDE 编辑窗口中，Javadoc 方式会提示相关注释，生成 Javadoc 可以正确输出相应注 释；在 IDE 中，工程调用方法时，不进入方法即可悬浮提示方法、参数、返回值的意义，提高 阅读效率。
2.所有的抽象方法（包括接口中的方法）必须要用 Javadoc 注释、除了返回值、参数、 异常说明外，还必须指出该方法做什么事情，实现什么功能。 说明：对子类的实现要求，或者调用注意事项，请一并说明。
3. 所有的类都必须添加创建者和创建日期。
4. 方法内部单行注释，在被注释语句上方另起一行，使用//注释。方法内部多行注释 使用/* */注释，注意与代码对齐。
5. 所有的枚举类型字段必须要有注释，说明每个数据项的用途
（七）编码原则
1.优先使用基本类型而不是装箱基本类型，当心无意识的自动装箱;
2.重写equals()时，总要重写hashCode();
3.始终要重写toString();
4.尽可能的使每个类或者成员不被外界访问；
5.避免创建不必要的对象
6.列表优于数组
7.优先考虑泛型和泛型方法
8.检查参数有效性
9.必要时进行保护性拷贝
10.避免过长的参数列表(尽量少于4个)
11.慎用可变参数
12.返回零长度的数组或集合，而不是Null
13.将局部变量的作用域最小化
14.如果需要精度计算，请避免使用float和double，使用BigDecimal,int或long进行计算
三、通过Powerdesigner等工具完成团队项目的数据库设计，并提供相应ER图。
3.1 主体
1 用户
2 管理员
3.2 数据库
1 用户信息数据库
2 管理员信息数据库
1，管理员数据库
2，普通用户数据库
E-R图：
四、队员阅读《构建之法》第１１章内容。进行项目的体系结构设计，并列出体系结构图。
五、描述组员在上述任务中的分工和工作量比例（这次任务的分配）。
|
团队成员 |
任务分工 |
工作量比例 |
|
李源淇 |
任务一、任务五以及燃尽图的工作任务 |
20% |
|
田龙威 |
通过Powerdesigner等工具完成团队项目的数据库设计以及E-R图的书写 讨论总结，将代码规范和编码原则发布。 制定团队的编码规范 |
20% |
|
王奕杰 |
20% |
|
|
陈炼栋 |
20% |
|
|
赖金明 |
进行项目的体系结构设计，并列出体系结构图。 |
20% |
六、gittee项目燃尽图：
