軟工團隊 - 系統設計

修改完善需求規格說明書

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

管理員層面沒有在需求中得到很好的體現。

沒有手機號驗證。

那時候回答的比較含糊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	測試、文章推薦算法

燃盡圖

TODOlist都在issue里。

燃盡圖：

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

本次任務分配比例

劉晨瑤李永盛蘇偉鵬張昭錫

20%	40%	5%	35%

轉載于:https://www.cnblogs.com/thousfeet/p/7745591.html

總結

以上是生活随笔為你收集整理的软工团队 - 系统设计的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。