白雪公主与七个爷爷——凡事预则立
| 这个作业属于哪个课程 | https://edu.cnblogs.com/campus/zswxy/software-engineering-2017-1 |
|---|---|
| 这个作业要求在哪里 | https://edu.cnblogs.com/campus/zswxy/software-engineering-2017-1/homework/10841 |
| 团队名称 | 白雪公主与七个爷爷 |
| 这个作业的目标 | 七天冲刺安排 |
| 作业正文 | 见下文 |
| 其他参考文献 | 代码规范 |
一、冲刺的时间计划安排(七天)
| 时间 | 安排 |
|---|---|
| 6.23 | 各自实现自己负责的前端部分 |
| 6.24 | 各自实现自己负责的前端部分并测试 |
| 6.25 | 整合所有前端，讨论并修改 |
| 6.26 | 各自实现自己负责的后端部分 |
| 6.27 | 各自实现自己负责的后端部分 |
| 6.28 | 整合所有的前后端，进行测试，讨论并修改 |
| 6.29 | 测试软件，进行完善 |
二、针对前几次作业的不足的地方进行思考和总结
三、需要改进的团队分工
| 工作人员 | 工作内容 |
|---|---|
| 梁明 | 打卡列表界面与后端实现 |
| 王佳 | 登录注册界面与后端实现 |
| 胡靓 | 番茄钟界面与功能实现 |
| 周佳欣 | 待办清单列表界面与后端实现 |
| 曾扬威 | 待办清单任务详情界面与后端实现 |
| 肖颢璇 | 新建打卡界面与后端实现 |
| 肖璐瑶 | 日历界面与后端实现 |
| 李子妍 | 个人中心界面与后端实现 |
由于大家的编程能力有限，时间比较急迫，在实现过程中可能会去除一些困难的部分，分工也会进行相应的变化。
四、团队的代码规范
4.1 命名风格
- 代码中的命名均不能以下划线或美元符号开始，也不能以下划线或美元符号结束。
- 反例：name / name / $name / name / name$ / name
- 代码中的命名严禁使用拼音与英文混合的方式，更不允许直接使用中文的方式。
- 类名使用 UpperCamelCase 风格，但以下情形例外：DO / BO / DTO / VO / AO / PO / UID 等。
- 正例：MarcoPolo / UserDO / XmlService / TcpUdpDeal / TaPromotion
- 反例：macroPolo / UserDo / XMLService / TCPUDPDeal / TAPromotion
- 方法名、参数名、成员变量、局部变量都统一使用 lowerCamelCase 风格，必须遵从驼峰形式。
- 正例： localValue / getHttpMessage() / inputUserId
- 常量命名全部大写，单词间用下划线隔开，力求语义表达完整清楚，不要嫌名字长。
- 正例：MAX_STOCK_COUNT
- 反例：MAX_COUNT
- 抽象类命名使用 Abstract 或 Base 开头；异常类命名使用 Exception 结尾；测试类 命名以它要测试的类的名称开始，以 Test 结尾。
- 包名统一使用小写，点分隔符之间有且仅有一个自然语义的英语单词。包名统一使用单数形式，但是类名如果有复数含义，类名可以使用复数形式。
- 正例：应用工具类包名为 com.alibaba.ai.core.util、类名为 MessageUtils（此规则参考 spring 的框架结构）
- 杜绝完全不规范的缩写，避免望文不知义。
- 反例：AbstractClass“缩写”命名成AbsClass；condition“缩写”命名成 condi，此类随 意缩写严重降低了代码的可阅读性。
4.2 代码格式
- 大括号的使用约定。如果是大括号内为空，则简洁地写成{}即可，不需要换行；如果是非空代码块则：
- 左大括号前不换行。
- 左大括号后换行。
- 右大括号前换行。
- 右大括号后还有 else 等代码则不换行；表示终止的右大括号后必须换行。
- if/for/while/switch/do 等保留字与括号之间都必须加空格。
- 采用 4 个空格缩进，禁止使用 tab 字符。
4.3 注释规约
- 类、类属性、类方法的注释必须使用 Javadoc 规范，使用/**内容*/格式，不得使用 // xxx 方式。
- 所有的抽象方法（包括接口中的方法）必须要用 Javadoc 注释、除了返回值、参数、异常说明外，还必须指出该方法做什么事情，实现什么功能。
- 说明：对子类的实现要求，或者调用注意事项，请一并说明。
- 所有的类都必须添加创建者和创建日期。
- 方法内部单行注释，在被注释语句上方另起一行，使用//注释。方法内部多行注释 使用/* */注释，注意与代码对齐。
- 所有的枚举类型字段必须要有注释，说明每个数据项的用途。
- 与其“半吊子”英文来注释，不如用中文注释把问题说清楚。专有名词与关键字保持英文原文即可。
- 代码修改的同时，注释也要进行相应的修改，尤其是参数、返回值、异常、核心逻辑等的修改。
五、构建之法
第十三章 软件测试
书本上提到了很多测试方法，我们可以选择一种适合的方法进行测试。测试这一方面我们接触的比较少，可能只会针对部分功能进行测试，。
第十四章 质量保障
对于一个软件来说，软件的质量是很重要的。只有团队里每个成员的能力获得提升，才能提高软件质量。
第十五章 稳定和发布阶段
身为软件的开发者，了解自己的软件有哪些BUG，有什么不足，发布前尽量完善软件功能。对每一个bug，采用相应的行动。
发布之后，开事后诸葛亮会议进行总结。
第十六章 IT行业的创新
创新不是随便的创造出一些不合实际的东西。而是根据用户实际需求创造出更好的体验的软件给用户。对于我们这些菜鸟来说，我认为思考创新还为时过早，没有技术，有再多的想法也是空想。
第十七章 人、绩效和职业道德
- 团队合作的阶段：
（1）萌芽阶段，就像小苗破土而出，柔弱但充满希望
（2）磨合阶段，就像一个人的青少年时期，充满了对个人、同伴和团队的疑惑和冲突
（3）规范阶段，从磨合阶段毕业，进入规范阶段的团队，成员们意识到光争吵时没有用的，大家还是要协同作战
（4）创造阶段，经历了萌芽、磨合、规范阶段，现在团队终于可以创造一些有意义的东西
- 无论是从事什么职业都要培养职业道德。团队合作的几个阶段中，要注意我们的身为软件工程的职业道德。
