- 课程名称：软件工程1916|W（福州大学）
- 作业要求：项目Beta冲刺）
- 团队名称：葫芦娃队
- 作业目标：尽力完成
团队博客
| 队员学号 | 队员昵称 | 博客地址 |
|---|---|---|
| 041602421 | der himmel | https://www.cnblogs.com/wenghaoo |
| 221600225 | wuliaoBoring | https://www.cnblogs.com/wuliaoBoring/ |
| 221600424 | BW.LIN | https://www.cnblogs.com/lbwblog/ |
| 221600432 | QZY | https://www.cnblogs.com/nuomituanzi/ 组长 |
| 221600440 | 小冰 | https://www.cnblogs.com/xiaobing666/ 转入 |
| 221600434 | 北风5620 | https://www.cnblogs.com/beifeng5620/ |
| 221600435 | XBN | https://www.cnblogs.com/xbnhhh/ |
1、讨论组长是否重选的议题和结论
结论否，因为项目是由组长提出的，相应负责更多，组长不重选但可以放权更多给组员，可以选出副组长
2&3、下一阶段需要改进完善的功能
完善：改进关卡设计，人物武器，可玩性平衡性竞技性的调整。
新增 :局域网连接
4、需要改进的团队分工（针对之前的不足，需要加强和改进团队协作和分工的地方）
分工在一开始时要充分考虑，不仅是组长分配时要考虑，组员接任务是也要考虑自己是否完成有困难，分工定好了，后期如果因为某些原因要更改就要付出相当大的代价。
测试部分：自己写哪部份的功能，改功能测试应该基本由他自己完成，这样写测试能更高效和可靠也能，能明白自己写的代码适不适合写测试（是不是把有一定功能代码写成函数分块便于测试，代码耦合度会不会过高）
5、需要改进的工具流程（版本控制、测试工具等）
版本控制：组员comit消息的规范要制定，要描述此次commit的工作任务。
测试工具：有一定功能代码写成函数分块便于测试，代码耦合度不应该过高，这样便于测试。
6、冲刺的时间计划安排
7、代码规范
一、注释规约（重）
-
【强制】所有的方法要完成返回值、参数、异常说明外，还必须指出该方法做什么事情，实现什么功能。这种描述不应该包括执行过程细节（它是怎么做的）
-
【强制】方法内部单行注释，在被注释语句上方另起一行，使用//注释。方法内部多行注释 使用/* */注释，注意与代码对齐。
-
【推荐】与其“半吊子”英文来注释，不如用中文注释把问题说清楚。专有名词与关键字保持英文原文即可。
反例：“TCP连接超时”解释成“传输控制协议连接超时”，理解反而费脑筋。 -
【推荐】代码修改的同时，注释也要进行相应的修改，尤其是参数、返回值、异常、核心逻辑等的修改。
说明：代码与注释更新不同步，就像路网与导航软件更新不同步一样，如果导航软件严重滞后，就失去了导航的意义。 -
【参考】谨慎注释掉代码。在上方详细说明，而不是简单地注释掉。如果无用，则删除。
-
说明：代码被注释掉有两种可能性：
- 后续会恢复此段代码逻辑。
- 永久不用。
- 前者如果没有备注信息，难以知晓注释动机。后者建议直接删掉（代码仓库保存了历史代码）。
二、命名风格
- 【强制】代码中的命名严禁使用拼音与英文混合的方式，更不允许直接使用中文的方式。
- 说明：正确的英文拼写和语法可以让阅读者易于理解，避免歧义。注意，即使纯拼音命名方式也要避免采用。国际通用的名称，可视同英文。
- 反例：
- DaZhePromotion [打折] 。
- getPingfenByName() [评分] 。
- int 某变量 = 3。
- 【强制】方法名、成员变量、类名使用 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 结尾。
- 【强制】杜绝完全不规范的缩写，避免望文不知义。反例：AbstractClass“缩写”命名成AbsClass；condition“缩写”命名成 condi，此类随 意缩写严重降低了代码的可阅读性。
- 【推荐】为了达到代码自解释的目标，任何自定义编程元素在命名时，使用尽量完整的单词组合来表达其意。
- 正例：在 JDK 中，表达原子更新的类名为：AtomicReferenceFieldUpdater。
- 反例：变量 int a 的随意命名方式。