团队六七周作业


完善版需求规格说明书


  • 《需求规格说明书》初稿不足之处:
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点时我还没能收集各部分完整的材料,希望以后可以尽量避免。

    ——金立清

返回目录

参考资料


返回目录