團隊做業--第二次

團隊做業--第二次

1-需求規格說明書的改變

1.改變了最初的分工安排
2.對最開始的app要求進行了更改，使更符合用戶需求

2-編碼規範

爲何要進行代碼規範

由於這個app是咱們小組五我的一塊兒編寫的代碼，每一個人編寫代碼的習慣不一樣寫出來代碼的格式也有很大的差別，因此須要統一代碼規範，這樣在後期修改的時候無論是誰在改，改誰的，都能一目瞭然的看清楚每行代碼的意思，更方便後期修改

代碼規範（參考博客：規範你的代碼編寫風格）

1. 標識符應當直觀且能夠拼讀，可望文知意，沒必要進行「解碼」。例如：標識符最好採用英文單詞或其組合，便於記憶和閱讀。切忌使用漢語拼音來命名。程序中的英文單詞通常不會太複雜，用詞應當準確。例如不要把CurrentValue寫成NowValue。
2. 標識符的長度應當符合「min-length && max-information」原則。
3. 命名規則儘可能與所採用的操做系統或開發工具的風格保持一致。　例如Windows應用程序的標識符一般採用「大小寫」混排的方式，如AddChild。
4. 程序中不要出現僅靠大小寫區分的類似的標識符。
5. 變量的名字應當使用「名詞」或者「形容詞＋名詞」。
6. 儘可能避免名字中出現數字編號，如Value1,Value2等，除非邏輯上的確須要編號。這是爲了防止程序員偷懶，不願爲命名動腦筋而致使產生無心義的名字（由於用數字編號最省事）
7. 指針以p開頭、

編碼原則（參考：編碼規則）

1. 關鍵詞和操做符之間加適當的空格。
2. 縮進：4個空格
   3.不容許把多個短語句寫在一行中，即一行只寫一條語句。 4.函數或過程的開始、結構的定義及循環、判斷等語句中的代碼都要採用縮進風格。
3. 編寫程序塊時‘{’和‘}’應各獨佔一行而且位於同一列，同時與引用它們的語句左對齊。在函數體的開始、類的定義、結構的定義、枚舉的定義以及if、for、do、while、switch、case語句中的程序都要採用如上的縮進方式。

代碼測試

1. 單元測試要求至少達到語句覆蓋。
2. 清理、整理或優化後的代碼要通過審查及測試。
3. 發現潛在的錯誤和迴歸性錯誤及可能須要改進的地方

3-數據庫設計與ER圖

4-後端架構設計

1. 基本的用戶驗證方案
   

此時就是後臺極簡化的架構：

1. 總體的架構設計
   

5-肯定團隊分工

1. 利用象限法肯定各個核心需求的優先級
   

2. 在博客中敘述並給出相應的WBS圖
   

3. 給出團隊各個成員認領的工做，列出當前團隊的TODOList
   劉辰：登錄註冊、決策、文案
   曾程：決策、美工、文案
   嚴域俊：遊戲分類、遊戲編寫、文案
   鄧煜坤：整合代碼、代碼規範、文案
   吳恆佚：遊戲分類、遊戲編寫、文案
   

6-組員在上述任務中的分工和工做量比例。

• 20172306 劉辰 ：20%
• 20172324 曾程 ：20%
• 20172325 鄧煜坤 ：20%
• 20172333 嚴域俊 ：20%
• 20172321 吳恆佚 ：20%
• 燃盡圖