软工团队 - 系统设计

软工团队 - 系统设计

修改完善需求规格说明书

针对栋哥在上周答辩中主要提到问题的相应改动

1. 管理员层面没有在需求中获得很好的体现。
2. 没有手机号验证。

那时候回答的比较含糊orz，因此在这里说明一下对此做出的解释和修改。

1. 对于第一点，咱们讨论的结果是至少在这学期先摒弃掉管理员这个需求。由于在咱们这个项目里面对于管理员的需求其实至关少的，管理员作的惟一事情就是审核被举报的不良分享，起到的做用是维护分享内容的优质性，可是这首先是创建在用户群体达到必定数量以后才须要考虑的问题，而在用户群体较小的初期有垃圾过滤基本上已经足够了。至少在这学期中只打算先造成一个用户类型惟一MVP。对此作出的改动是在需求文档中把管理员相关的在验收标准中完全去掉了。

2. 对于第二点，一开始咱们是不想强迫实名的，可是没考虑到如今上线产品的要求必需要实名....可是至少在这学期仍是先不考虑，由于光是发手机验证啊等等又一堆事，这是上线前才须要作的事情。作出的改动是在类图和数据库设计里把手机号这一条属性加上去了，但也仅是加上个名号，留个坑后面填。

验收标准的改动

24号座谈会以后听取了邹老师的建议把实现关键字匹配算法放在首要位置。作出的改动是在Alpha阶段必须让Android端核心dev（1人）在完成框架后就先专心去把算法先实现出来，确保在Beta能投入使用，而把各界面模块等的实现交给其余dev（3人）完成。而Beta阶段只完成进一步算法改善（安卓端关键字匹配算法的优化、服务器端垃圾过滤算法），而延后应用锁等零零碎碎的其余辅助需求。

对需求规格说明书的上述改动已签入github。

团队编码规范

由于团队成员基本没有充分的编码经历，因此选择了大量借鉴其余经典规范。

Android代码规范

选择了github上一份star和fork数较多的一份规范。缘由是在比对了谷歌在安卓方面给出的《面向贡献者的代码样式指南》后，发现这份代码规范基本都有涉及，而且增添了更详细的规范要求，而其中增长的一些规范要求与《阿里巴巴Java开发手册》中的一些要求不谋而合。并在这些基础上，询问了已经实习的安卓岗学长，根据他的建议更改了一些内容。

（文档连接：Android编码规范）

PHP代码规范

选择了由 PHPHub 社区翻译的 PSR 标准，PSR 是 PHP Standard Recommendations 的简写，由 PHP FIG 组织制定的 PHP 规范，是 PHP 开发的实践标准。咱们根据翻译的多篇文档，选取了 PSR-1 基础编码规范、PSR-2 编码风格规范、PSR-4 自动加载规范做为适用于本项目开发的 PHP 规范。

（文档连接：PHP编码规范）

这几天咱们会再开一次小会具体探讨是否须要进一步增改。(10.30已完成)

Github使用规范

https://www.zybuluo.com/thousfeet/note/933363

数据库设计

（数据库设计规范：https://www.biaodianfu.com/mysql-best-practices.html）

Android本地数据库

Android 端的数据库使用 WorkBench 设计。

服务器数据库

服务器端的数据库使用 WWW SQL Designer 和 Navicat 设计。

虽然两张图长得并不像是个数据库课上那样的ER图，但其中的各实体、属性、关系也已经体现出来，就再也不去画那种又大张排版又很丑的传统ER图了。

架构设计

（大图地址）

Android端

整个安卓端采用MVP架构。

View对应于Activity，负责View的绘制以及与用户交互（根据原型设计，里面有五个Fragment），Model则是负责业务逻辑与实体模型（存储、检索、操做数据），Presenter负责完成View和Model的交互。Model层中的Data Repository用来对Presenter层屏蔽数据细节。ViewInterface是须要View实现的接口、PresenterInterface则是Presenter须要实现的接口（两者都是为了下降耦合度）。OkHttp3和Retrofit2是网络通讯库，用来与服务器端进行通讯，FastJson用来处理服务器传输过来的Json包，LitaPal是一个采用ORM（对象关系映射）的数据库框架，处理数据的存储。

服务器端

面向 Android 端，服务器端使用了 RESTful API 的风格。采用 PHP 时下流行的 Laravel 5.5 框架，同时采用了 MySQL 数据库和 Nginx 提供 Web 服务。

Laravel 框架使用 MVC 模型架构，但因为咱们的 View 是存在于 Android 端中的，因此服务端只须要 Model、Controller 和 Router 层。

参考了学长的Laravel 设计架构，咱们得出如下的设计细节。

Router 层承担了 API 接口的功能，在 Android 端和服务器端间传递错误代码、具体内容。

Model 层定义了咱们须要操控的 User、Note、Article 等模型，以供 Controller 操做，实际上的模型存在于数据库中。

Controller 层包含了 AuthController、UserController、NoteController、ArticleController 这几个主要的控制器。

AuthController 进行验证用户登陆等受权操做。

UserController 进行修改用户信息、管理用户等操做。

NoteController 管理记录，实现分享逻辑等等。

ArticleController 进行抓取文章、推荐文章的相关操做，包含大量核心代码。

在数据存储方面，因为咱们有图片和语音等体积大的多媒体文件，所以咱们选取七牛云进行对象存储。七牛云是流行的对象云存储服务，有较大的免费额度和丰富的 Android、PHP API。当 Android 端须要存储多媒体文件时，经过 API 向服务器申请上传权限，服务器经过验证后返回上传凭证。Android 使用上传凭证向七牛云上传文件，七牛云返回上传结果。服务器向七牛云发起回调，七牛云返回回调结果。这样就解决了服务器带宽和存储容量小，又有大量大致积多媒体文件须要上传的难题。

在数据库和数据操做方面，使用 Eloquent ORM，封装对数据的处理和与数据库的交互，封装其外键关系。为防止 SQL 注入的发生，杜绝使用原生的 SQL 查询，使用 ORM 和 Laravel 提供的链式查询机制，让框架编译 SQL 语言进行查询，既保证了开发效率又提升了安全性。

日志记录方面，将服务器的操做和发生的异常都记录在日志文件中，以备往后检索。

考虑到迭代和解耦，将自定义的全局变量、自定义的辅助方法等，都定义在应用的服务提供者文件中，这样会加载到全局。

(具体业务逻辑表已更新)

肯定团队分工

需求四象限及各阶段计划

WBS图

（标红旗的是重点任务）

部分issue截图

（最右侧的数字tag是工做量，须要在安装github插件ZenHub下查看）

部分teambition截图

团队成员认领工做

人员	任务
522	把控项目进度、审核和签入代码等
541	安卓MVP框架搭建、安卓端编码（首页模块、各类工具类）
517	服务端编码
533	安卓端编码（记录、文章模块）
113	安卓端编码（我的信息模块）
328	安卓端编码（流星、登陆注册模块）
331	服务端编码（文章模块）
506	测试、文章推荐算法

燃尽图

TODOlist都在issue里。

燃尽图：

（推荐一下github插件ZenHub，挺好用的）

本次任务分配比例

刘晨瑶	李永盛	苏伟鹏	张昭锡
20%	40%	5%	35%