软工团队 - 系统设计

修改完善需求规格说明书

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

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

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

对于第一点，我们讨论的结果是至少在这学期先摒弃掉管理员这个需求。因为在我们这个项目里面对于管理员的需求其实相当少的，管理员做的唯一事情就是审核被举报的不良分享，起到的作用是维护分享内容的优质性，但是这首先是建立在用户群体达到一定数量之后才需要考虑的问题，而在用户群体较小的初期有垃圾过滤基本上已经足够了。至少在这学期中只打算先形成一个用户类型唯一MVP。对此做出的改动是在需求文档中把管理员相关的在验收标准中彻底去掉了。
对于第二点，一开始我们是不想强迫实名的，但是没考虑到现在上线产品的要求必须要实名....但是至少在这学期还是先不考虑，因为光是发手机验证啊等等又一堆事，这是上线前才需要做的事情。做出的改动是在类图和数据库设计里把手机号这一条属性加上去了，但也仅是加上个名号，留个坑后面填。

验收标准的改动

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	测试、文章推荐算法