1. 团队介绍
团队名：易软【E-Soft】
队长：陈传诚
队员：刘志—孟祥鑫—申佳栋—花福强—段应官—张哲—陈雪健—陈相君—尘超然
合影：
2. 团队规范
2.1 变量命名规范
命名规则：力求做到统一、达意和简洁，驼峰法则，符合标识符规则。
包名：使用小写字母如
com.learn不要com.Learn
类名：首字母大写，如TextDemo，不要textdemo变量：知名见意，小写字母，多个单词下划线，如：数量用
int num,如：累计用int count,如学生年龄用studentAge方法名：首字母小写，如 addOrder() 不要 AddOrder()，动词在前，如 addOrder()，不要orderAdd()
静态变量名：
public static final int num=3;
2.2 注释规范
- 注释宜少二精，不宜多而滥。
- 命名达意，结构清晰， 类和方法等责任明确，往往不需要，或者只需要很少注释，就可以让人读懂。
- 不能正确表达代码意义的注释，只会损害代码的可读性。
- 过于详细的注释，对显而易见的代码添加的注释，罗嗦的注释，还不如不写
- 尽量避免在注释中使用缩写，特别是不常用缩写。
- 注释的位置应与被描述的代码相邻，可以放在代码的上方或右方，不可放在下方。
- 边写代码边注释，修改代码同时修改相应的注释，以保证注释与代码的一致性。不再有用的注释要删除。
- 块级别注释，单行用//，多行用/* */。
2.3 代码块格式
缩进风格，大括号的开始在代码块开始的行尾，闭合在和代码块同一缩进的行首，例如：
for(int i=0; i<10; i++){
count++;
}
空行的使用，将一组操作放在一起，不同操作用空行隔开，如定义类时：
class A {
int b=10;
void show();
}
不能
class A {
int b=10;
void show();
}
3. 团队模式
3.1 交响乐团模式：各司其职，想交响乐队一样
优点：各司其职，重在执行
缺点：呆板
3.2 明星模式：主治医师模式运用到极点
优点：对“明星”个人的成长进步可能会有所帮助
缺点：团队模式强调的是团队的作用，而不是个人的独角戏，这种模式违背了团队模式的初衷，效率也很低