軟工團隊 - 系統設計

軟工團隊 - 系統設計

修改完善需求規格說明書

針對棟哥在上週答辯中主要提到問題的相應改動

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%