团队六七周作业
完善版需求规格说明书
- 《需求规格说明书》初稿不足之处：
1.开发工具写错
2.游戏风格与游戏特点内容重复
制定团队编码规范
阅读《构建之法》第四章内容，讨论并总结
- 使用的工具
JDK：
IDEA：
Android Studio：
编码规范
目的
制定统一的编码规范，使项目组成员养成良好的编程习惯，提高代码的效率及可读性，使代码达到很好的整合控制。依据
仿照Sun公司基本的JAVA规范。-
具体规范
3.1 编码风格
缩进
1. 建议以4个空格为单位。
2. 语句块的"{"、"}"配对对齐，并与其前一行对齐，语句块类的语句缩进建议每个"{"、"}"单独占一行，便于匹对。空格
原则上变量、类、常量数据和函数在其类型，修饰名称之间适当空格并据情况对齐。
关键字原则上空一格，如：if ( ... 等。运算符的空格规定如下："::"、"->"、"["、"]"、"++"、"--"、"~"、"!"、"+"、"-"（指正负号）、"&"（引用）等几个运算符两边不加空格（其中单目运算符系指与操作数相连的一边），
其它运算符（包括大多数二目运算符和三目运算符"?:"两边均加一空格，在作函数定义时还可据情况多空或不空格来对齐，但在函数实现时可以不用。","运算符只在其后空一格，需对齐时也可不空或多空格。不论是否有括号，对语句行后加的注释应用适当空格与语句隔开并尽可能对齐。个人认为此项可以依照个人习惯决定遵循与否。-
对齐
原则上关系密切的行应对齐，对齐包括类型、修饰、名称、参数等各部分对齐。另每一行的长度不应超过屏幕太多，必要时适当换行，换行时尽可能在","处或运算符处，换行后最好以运算符打头，并且以下各行均以该语句首行缩进，但该语句仍以首行的缩进为准，即如其下一行为“{”应与首行对齐。变量定义最好通过添加空格形成对齐，同一类型的变量最好放在一起。如下例所示：
int Value;
int Result;
int Length;
个人认为此项可以依照个人习惯决定遵循与否。
- 空行
不得存在无规则的空行，比如说连续十个空行。程序文件结构各部分之间空两行，若不必要也可只空一行，各函数实现之间一般空两行，由于每个函数还要有函数说明注释，故通常只需空一行或不空，但对于没有函数说明的情况至少应再空一行。对自己写的函数，建议也加上“//------”做分隔。函数内部数据与代码之间应空至少一行，代码中适当处应以空行空开，建议在代码中出现变量声明时，在其前空一行。类中四个“p”之间至少空一行，在其中的数据与函数之间也应空行。
- 注释
JAVA代码注释
- 综述
注释是软件可读性的具体体现。
程序注释量一般占程序编码量的20%，软件工程要求不少于20%。
程序注释不能用抽象的语言，要精确表达出程序的处理说明。
注释必不可少，但也不应过多，不要被动的为写注释而写注释。
- 以下是四种必要的注释：
A 标题、附加说明。
B 函数、类等的说明。
对几乎每个函数都应有适当的说明，通常加在函数实现之前，在没有函数实现部分的情况下则加在函数原型前，其内容主要是函数的功能、目的、算法等说明，参数说明、返回值说明等，必要时还要有一些如特别的软硬件要求等说明。
C 在代码不明晰或不可移植处必须有一定的说明。
D 及少量的其它注释，如自定义变量的注释等。
注释有块注释和行注释两种，分别是指："/**/"和"//"
-
3.2 代码效率
综述
编程过程中一定要考虑代码执行的效率，大家在以后的开发工作中有什么具体的经验可以继续完善。
具体实现
把要循环的数组或列表，长度赋予某个变量，在for循环体中调用改变量即可。
-
异常处理
程序处理 1. 在程序调试过程中可以让程序抛出异常，以便发现问题;当程序调试完毕须捕获异常，进行处理。
2. 对于空指针一样，一定要在程序编写时考虑到这种情况，并做相应处理。
-
日常交流
4.1互相促进
a. 项目开发过程中，按照功能模块来划分每个人的任务，当有两个人完成各自模块后，进行交换交流，除检查其功能是否完成外，互相检查代码规范，代码质量是非常重要的。
b. 可以在程序开发过程中，多考虑一层，考虑功能的重用性
c. 每周一进行项目组总节，通告项目组人员自己学到什么，与大家分享，共同提高。
d. 有好的想法或者对项目组有益的都可以提出来讨论研究。
数据库设计
- 《打地鼠》cmd文件
- ER图
后端架构设计
Redis做缓存系统，MySQL做数据库。
尽量把重复实现的模块部署为远程服务，新增的业务调用远程服务提供的功能来实现相关的业务，不依赖于里面具体的代码实现，例如将用户、管理员登陆模块整合，来减少程序的累赘。
App操作中由于经常涉及用户登录操作，登录就需要使用到用户名和密码，为了安全起见，在登录密码时显示密码的次数越少越好，因此，最好是使用https协议。
基本的方案是所有涉及安全性的API请求都必须使用HTTPS协议。
就项目启动后的后台来看，根据程序实际情况，不考虑分布式部署架构，尽量使用一开始就使用Redis。好处：既能用作缓存，又能充当队列服务，而且并发性能高，能在长时间内应对业务压力，非常适合初期的项目。并且可以使用Redis验证用户信息，充当消息队列。而文件服务初期可以选择文件云存储服务，减少开发者的压力。
关于登陆方面服务器接收到app发送的用户名和密码后，验证用户名和密码是否正确。
如果错误则返回错误信息。如果验证正确，生成一个随机的不重复的token字符串（例如"daf32da456hfdh"），在Redis中维护一个映视表，建立token字符串和用户信息的对应关系表。就类似于有人希望进入一个上了锁的房间，他使用用户名和密码打开了这把锁后，进入房间，找到房间管理员，让管理员提供一把钥匙。
数据转码。
我们需要处理多个不同设备，多个操作系统和屏幕分辨率，我们的内容存储和处理时应与设备无关。所以，图像和视频的转码是必不可少的。我们的应用程序需要收集设备的配置，如内存、编码和屏幕分辨率，作为API的上下文。我们的API应该使用此上下文来选择内容版本。基于我们接受到的设备上下文，我们可以预先准备好一些最多的被请求的版本的内容。可以使用FFMPEG转码，FFMPEG是最可靠和应用最广的转码框架。可以修改FFMPEG，使其满足需求。转码是在数据输入端完成的。
由于网络环境，关键是要尽可能节省资源，使通信尽可能地轻量。我们所有的HTTP请求都使用okhttp客户端，okhttp使用SPDY协议，能够弹性处理连接失败，透明恢复。总而言之，尽可能将麻烦的事情交给专业人员来完成。同理，通讯需求，都可以切换到MQTT，这是一个轻量级的机器对机器的连接协议。
TODOList
| 学号 | 组员 | 分工 | 用时 | 工作量百分比 |
|---|---|---|---|---|
| 20162309 | 邢天岳 | 数据库设计 | 1h | 15% |
| 20162311 | 张之睿 | 完善版需求规格说明书 | 1h | 15% |
| 20162312 | 张家铖 | 制定团队编码规范 | 2h | 30% |
| 20162313 | 苑洪铭 | 后端架构设计 | 45min | 12% |
| 20162324 | 春旺 | 需求象限、WBS图、功能分配截图、燃尽图 | 2h | 30% |
| 20162325 | 金立清 | 团队分工&督促进度&编写博客 | 2h | 30% |
总结与反思
1.在分任务的时候，能力强的组员也容易避重就轻，这就让剩下的同学比较难做了…
2.大家对自己要完成的任务，认知上并不清晰明了，不太懂老师布置的要求和意图以及自己究竟如何下手。
-
3.这周因为各种事情，周日24点时我还没能收集各部分完整的材料，希望以后可以尽量避免。
——金立清