团队做业--第二次

团队做业--第二次

1-需求规格说明书的改变

1.改变了最初的分工安排
2.对最开始的app要求进行了更改，使更符合用户需求

2-编码规范

为何要进行代码规范

由于这个app是咱们小组五我的一块儿编写的代码，每一个人编写代码的习惯不一样写出来代码的格式也有很大的差别，因此须要统一代码规范，这样在后期修改的时候无论是谁在改，改谁的，都能一目了然的看清楚每行代码的意思，更方便后期修改

代码规范（参考博客：规范你的代码编写风格）

1. 标识符应当直观且能够拼读，可望文知意，没必要进行“解码”。例如：标识符最好采用英文单词或其组合，便于记忆和阅读。切忌使用汉语拼音来命名。程序中的英文单词通常不会太复杂，用词应当准确。例如不要把CurrentValue写成NowValue。
2. 标识符的长度应当符合“min-length && max-information”原则。
3. 命名规则尽可能与所采用的操做系统或开发工具的风格保持一致。　例如Windows应用程序的标识符一般采用“大小写”混排的方式，如AddChild。
4. 程序中不要出现仅靠大小写区分的类似的标识符。
5. 变量的名字应当使用“名词”或者“形容词＋名词”。
6. 尽可能避免名字中出现数字编号，如Value1,Value2等，除非逻辑上的确须要编号。这是为了防止程序员偷懒，不愿为命名动脑筋而致使产生无心义的名字（由于用数字编号最省事）
7. 指针以p开头、

编码原则（参考：编码规则）

1. 关键词和操做符之间加适当的空格。
2. 缩进：4个空格
   3.不容许把多个短语句写在一行中，即一行只写一条语句。 4.函数或过程的开始、结构的定义及循环、判断等语句中的代码都要采用缩进风格。
3. 编写程序块时‘{’和‘}’应各独占一行而且位于同一列，同时与引用它们的语句左对齐。在函数体的开始、类的定义、结构的定义、枚举的定义以及if、for、do、while、switch、case语句中的程序都要采用如上的缩进方式。

代码测试

1. 单元测试要求至少达到语句覆盖。
2. 清理、整理或优化后的代码要通过审查及测试。
3. 发现潜在的错误和回归性错误及可能须要改进的地方

3-数据库设计与ER图

4-后端架构设计

1. 基本的用户验证方案
   

此时就是后台极简化的架构：

1. 总体的架构设计
   

5-肯定团队分工

1. 利用象限法肯定各个核心需求的优先级
   

2. 在博客中叙述并给出相应的WBS图
   

3. 给出团队各个成员认领的工做，列出当前团队的TODOList
   刘辰：登录注册、决策、文案
   曾程：决策、美工、文案
   严域俊：游戏分类、游戏编写、文案
   邓煜坤：整合代码、代码规范、文案
   吴恒佚：游戏分类、游戏编写、文案
   

6-组员在上述任务中的分工和工做量比例。

• 20172306 刘辰 ：20%
• 20172324 曾程 ：20%
• 20172325 邓煜坤 ：20%
• 20172333 严域俊 ：20%
• 20172321 吴恒佚 ：20%
• 燃尽图