1.冲刺的时间计划安排
| 时间 | 团队任务安排 |
|---|---|
| 6.25 | 前端界面设计，后端处理数据与提供接口 |
| 6.26 | 登录界面与后端接口 |
| 6.27 | 学生界面与后端接口 |
| 6.28 | 教师界面与后端接口 |
| 6.29 | 教研室主任界面与后端接口 |
| 6.30 | 管理员界面与后端接口 |
| 7.1 | 测试与总结 |
2.针对前几次作业不足的地方进行思考和总结
- 团队作业每次分配任务是个难题，总会有分配不均，有时候会让队员参与到不高。
- 有时候队员参与度不高，大家太被动。不分配任务没有主动性。
- 讨论较少，经常性的分配完任务就是这个人去完成，没有大家一起讨论的习惯。
- 争对前面几次的团队作业有努力的地方也有不足的地方。
- 努力：分配好的任务大家都会去认真完成，不会的也会多问。
- 不足：遇到问题都会去解决，但是能够做到更好却没有去做，只能说尽量完成了作业任务。有时候会有段消极的态度。
3.需要改进的团队分工（针对之前的不足，需要加强和改进的团队协作和分工的地方）
改进
（1）团队之间应该多进行线上线下的交流，保证每条消息都在第一时间被所有的成员知晓并做出相应的改变
（2）每个成员之间的分工要明确，各司其职，调动所有成员的积极性
4.团队的代码规范
一、命名风格
1.【强制】代码中的命名均不能以下划线或美元符号开始，也不能以下划线或美元符号结束。
反例：name / name / $name / name / name$ / name
2.【强制】代码中的命名严禁使用拼音与英文混合的方式，更不允许直接使用中文的方式。
说明：正确的英文拼写和语法可以让阅读者易于理解，避免歧义。注意，即使纯拼音命名方式也要避免采用。国际通用的名称，可视同英文。
反例：DaZhePromotion [打折] / getPingfenByName() [评分] / int 某变量 = 3
3.【强制】类名使用 UpperCamelCase 风格，但以下情形例外：DO / BO / DTO / VO / AO / PO / UID 等。
正例：MarcoPolo / UserDO / XmlService / TcpUdpDeal / TaPromotion
反例：macroPolo / UserDo / XMLService / TCPUDPDeal / TAPromotion
4.【强制】方法名、参数名、成员变量、局部变量都统一使用 lowerCamelCase 风格，必须遵从驼峰形式。
正例： localValue / getHttpMessage() / inputUserId
5.【强制】常量命名全部大写，单词间用下划线隔开，力求语义表达完整清楚，不要嫌名字长。
正例：MAX_STOCK_COUNT
反例：MAX_COUNT
6.【强制】抽象类命名使用 Abstract 或 Base 开头；异常类命名使用 Exception 结尾；测试类 命名以它要测试的类的名称开始，以 Test 结尾。
7.【强制】包名统一使用小写，点分隔符之间有且仅有一个自然语义的英语单词。包名统一使用单数形式，但是类名如果有复数含义，类名可以使用复数形式。
正例：应用工具类包名为 com.alibaba.ai.core.util、类名为 MessageUtils（此规则参考 spring 的框架结构）
8.【强制】杜绝完全不规范的缩写，避免望文不知义。
反例：AbstractClass“缩写”命名成AbsClass；condition“缩写”命名成 condi，此类随 意缩写严重降低了代码的可阅读性。
【推荐】为了达到代码自解释的目标，任何自定义编程元素在命名时，使用尽量完整的单词组合来表达其意。
正例：在 JDK 中，表达原子更新的类名为：AtomicReferenceFieldUpdater。
反例：变量 int a 的随意命名方式。
二、代码格式
1.【强制】大括号的使用约定。如果是大括号内为空，则简洁地写成{}即可，不需要换行；如果是非空代码块则：
左大括号前不换行。
左大括号后换行。
右大括号前换行。
右大括号后还有 else 等代码则不换行；表示终止的右大括号后必须换行。
2.【强制】if/for/while/switch/do 等保留字与括号之间都必须加空格。
【强制】采用 4 个空格缩进，禁止使用 tab 字符。
三、注释规约
1.【强制】类、类属性、类方法的注释必须使用 Javadoc 规范，使用/**内容/格式，不得使用 // xxx 方式。
说明：在 IDE 编辑窗口中，Javadoc 方式会提示相关注释，生成 Javadoc 可以正确输出相应注释；在 IDE 中，工程调用方法时，不进入方法即可悬浮提示方法、参数、返回值的意义，提高阅读效率。
2.【强制】所有的抽象方法（包括接口中的方法）必须要用 Javadoc 注释、除了返回值、参数、异常说明外，还必须指出该方法做什么事情，实现什么功能。
说明：对子类的实现要求，或者调用注意事项，请一并说明。
3.【强制】所有的类都必须添加创建者和创建日期。
4.【强制】方法内部单行注释，在被注释语句上方另起一行，使用//注释。方法内部多行注释 使用/ */注释，注意与代码对齐。
5.【强制】所有的枚举类型字段必须要有注释，说明每个数据项的用途。
【推荐】与其“半吊子”英文来注释，不如用中文注释把问题说清楚。专有名词与关键字保持英文原文即可。
反例：“TCP连接超时”解释成“传输控制协议连接超时”，理解反而费脑筋。
【推荐】代码修改的同时，注释也要进行相应的修改，尤其是参数、返回值、异常、核心逻辑等的修改。
说明：代码与注释更新不同步，就像路网与导航软件更新不同步一样，如果导航软件严重滞后，就失去了导航的意义。
【参考】谨慎注释掉代码。在上方详细说明，而不是简单地注释掉。如果无用，则删除。
说明：代码被注释掉有两种可能性：
后续会恢复此段代码逻辑。
永久不用。
前者如果没有备注信息，难以知晓注释动机。后者建议直接删掉（代码仓库保存了历史代码）。
5.阅读构建之法13-17章
《构建之法》：
第13章：软件测试
第14章：质量保障
第15章：稳定和发布阶段
第16章：IT行业的创新
第17章：人，绩效和职业道德
6.建立团队项目的github仓库，并将连接附在随笔的末尾
团队Github：
https://github.com/YinChuanLiu/Rebuild_System