第四次團隊作業——系統設計
一、團隊計劃>
1.更改了引言部分，因為這邊作為文件的開頭，需要簡短地介紹整個專案的背景。所以新添編碼目的與背景，具體內容如下：
編碼目的：軟體需求規格說明描述了隨手拍app專案的軟體需求和規格，為開發人員提供軟體的總體要求，明確所要開發的軟體應具有的功能、效能與介面，使系統分析人員及軟體開發人員能清楚地瞭解使用者的需求。提供了驗收標準，做為後面使用者驗收測試軟體的標準。
本文件的預期讀者有客戶（使用者、管理員），專案經理，開發人員以及跟該專案相關的其他競爭人員和無關人員。
背景:本文件介紹的產品是旅圖app，該系統面向熱愛生活，喜歡旅遊，喜好記錄生活的眾多使用者。能為其提供方便的記錄，快捷的檢視，優美的介面，充滿味道的瀏覽。該專案由“606notconnected”團隊統一開發。主要是為了能夠讓使用者在生活或者旅行中，對所見所聞有所感時，能夠便捷的記錄，摘錄；能夠在地圖上，檢視自己的生活路線，檢視自己的足跡，檢視自己的回憶。
2.由於第一次編寫時，不是太清楚需要展示什麼，所以有關於軟體本身的執行環境規定就沒有做相應的解釋，會導致一些處理上的誤差，所以這次加入裝置、開發環境、介面、控制。
裝置
作業系統為 windows server 2012 R2的伺服器
裝有android 4.0以上的手機
開發環境
vistual studio 2015
Mysql 5.1
Android studio 1.5.1
阿里雲 windows server 2012 R2
介面
硬體介面
無
軟體介面
使用者上傳更新個人資訊、獲取個人資訊
使用者獲取他人個人資訊
使用者新增、刪除關注
使用者上傳圖片、下載圖片、編輯圖片資訊
使用者上傳路線、獲取路線資訊、編輯路線資訊
通訊介面
採用TCP/IP 協議進行通訊
擬採用 Socket + Json 格式進行通訊
控制:無
3.上一次在聽了同學間的講解，發現忽視了有關言論與照片的稽核問題，所以有關這方面管理員的設定進行了相應的新增。
二、 編碼規範：
1.格式規範
1.1 原始檔結構
一個原始檔包含(按順序地)：
1>. package 語句
2>. import 語句
3>.一個頂級類(只有一個)
1>. package 語句不換行(即 package 語句寫在一行裡)
2>. import 不要使用萬用字元
即，不要出現類似這樣的 import 語句：import java.util.*;
不要換行
import 語句不換行，列限制(4.4 節)並不適用於 import 語句。(每個 import 語句獨立成行)
順序和間距
import 語句可分為以下幾組，按照這個順序，每組由一個空行分隔：
所有的靜態匯入獨立成組
com.google imports(僅當這個原始檔是在 com.google 包下)
第三方的包。每個頂級包為一組，字典序。例如：android, com, junit, org, sun
java imports
javax imports
3>. 只有一個頂級類宣告
每個頂級類都在一個與它同名的原始檔中(當然，還包含.java 字尾)。
例外：package-info.java，該檔案中可沒有 package-info 類。
2.縮排：我們不採用 Tab 鍵，而是手動輸入 4 個空格。
雖然 Tab 鍵一般為 4 個空格鍵，但在很多的編輯器中都可以擴充 Tab 鍵為多個空格鍵。不採
用 Tab 鍵理由是不同情況可能顯示不同的長度，嚴重影響閱讀體驗。
2.1 行寬：限定為 100 個字元
2.2括號：在複雜的表示式中，用括號清楚地表示邏輯優先順序
使讀者能夠快速、清楚看出表示式的運算順序
2.3 斷行與空白行{}:所有的‘{’‘}’各佔一行
2.4分行：多條語句不要放在同一行，
3 命名規範
首要原則--見名知意。普通變數採用 Camel 法，並採用名詞或者組合名詞來命名。而型別、
類、函式名採用 Pascal 法，並採用動詞或者動賓的方式命名。宏則全部採用大寫字母，採
用名詞或者組合名詞來命名，多個詞之間用下劃線連線。
3.1 變數（variables）:採用 Camel 命名法。類中控制元件名稱必須與 xml 佈局 id 保持一致。
用統一的量詞透過在結尾處放置一個量詞，就可建立更加統一的變數，它們更容易理解，也
更 容 易 搜 索 。 例 如 ， 請 使 用 strCustomerFirst 和 strCustomerLast ， 而 不 要 使 用
strFirstCustomer 和 strLastCustomer。
3.2 包（packages）: 採用反域名命名規則，全部使用小寫字母。一級包名為 com，二級
包名為 xx（可以是公司或則個人的隨便），三級包名根據應用進行命名，四級包名為模組名
或層級名
3.3 類（classes）：名詞，採用 Pascal 命名法，儘量避免縮寫，除非該縮寫是眾所周知
的， 比如 HTML,URL，如果類名稱中包含單詞縮寫，則單詞縮寫的每個字母均應大寫。
3.4 layout 中的 id 命名 命名模式為：view 縮寫_模組名稱_view 的邏輯名稱
4 函式使用
4.1 非排程函式應減少或防止控制引數，儘量只使用資料引數。
4.2 除非必要，最好不要把與函式返回值型別不同的變數，以編譯系統預設的轉換方式
或強制的轉換方式作為返回值返回。
4.3 在呼叫函式填寫引數時，應儘量減少沒有必要的預設資料型別轉換或強制資料型別
轉換。
4.4 設計高扇入、合理扇出（小於 7）的函式。
說明：扇出是指一個函式直接呼叫（控制）其它函式的數目，而扇入是指有多少上級函式調
用它。
4.5 避免使用 BOOL 引數。
4.6 對於提供了返回值的函式，在引用時最好使用其返回值。
4.7 當一個過程（函式）中對較長變數（一般是結構的成員）有較多引用時，可以用一
個意義相當的宏代替。
5.註釋規範
1）、函式頭的註釋 對於函式，應該從“功能”，“引數”，“返回值”、“主要思路”、
“呼叫方法”、“日期”六個方面用如下格式註釋：
//程式開始
//=//
//功能：
//引數：
//入口
//出口
//返回；對返回值有錯誤編碼的要求列出錯誤編碼
//=======================// 函式名
(……)
//程式說明結束
①對於某些函式，其部分引數為傳入值，而部分引數為傳出值，所以對引數要詳細說明該
引數是入口引數，還是出口引數，對於某些意義不明確的引數還要做詳細說明（例如：以角
度作為引數時，要說明該角度引數是以弧度（PI）,還是以度為單位）,對既是入口又是出口
的變數應該在入口和出口處同時標明。等等。
②函式的註釋應該放置在函式的標頭檔案中，在實現檔案中的該函式的實現部分應該同時放置
該註釋。
③在註釋中應該詳細說明函式的主要實現思路、特別要註明自己的一些想法，如果有必要則
應該寫明對想法產生的來由。對一些模仿的函式應該註釋上函式的出處。
④在註釋中詳細註明函式的適當呼叫方法，對於返回值的處理方法等。在註釋中要強調呼叫
時的危險方面，可能出錯的地方