团队六七周作业

完善版需求规格说明书

  • 《需求规格说明书》初稿不足之处：
1.开发工具写错
2.游戏风格与游戏特点内容重复

返回目录

制定团队编码规范

阅读《构建之法》第四章内容，讨论并总结

  • 使用的工具
    JDK：
    IDEA：
    Android Studio：

编码规范

  1. 目的
    制定统一的编码规范，使项目组成员养成良好的编程习惯，提高代码的效率及可读性，使代码达到很好的整合控制。

  2. 依据
    仿照Sun公司基本的JAVA规范。

  3. 具体规范

    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.	对于空指针一样，一定要在程序编写时考虑到这种情况，并做相应处理。

  1. 日常交流

    4.1互相促进

     a.	项目开发过程中，按照功能模块来划分每个人的任务，当有两个人完成各自模块后，进行交换交流，除检查其功能是否完成外，互相检查代码规范，代码质量是非常重要的。
 b.	可以在程序开发过程中，多考虑一层，考虑功能的重用性
 c.	每周一进行项目组总节，通告项目组人员自己学到什么，与大家分享，共同提高。
 d.	有好的想法或者对项目组有益的都可以提出来讨论研究。

返回目录

数据库设计

返回目录

后端架构设计

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点时我还没能收集各部分完整的材料，希望以后可以尽量避免。

    ——金立清

返回目录

参考资料

返回目录