團隊作業--第二次

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

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

2-編碼規范

為什么要進行代碼規范

因為這個app是我們小組五個人一起編寫的代碼，每個人編寫代碼的習慣不同寫出來代碼的格式也有很大的差異，所以需要統一代碼規范，這樣在后期修改的時候不管是誰在改，改誰的，都能一目了然的看清楚每行代碼的意思，更方便后期修改

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

標識符應當直觀且可以拼讀，可望文知意，不必進行“解碼”。例如：標識符最好采用英文單詞或其組合，便于記憶和閱讀。切忌使用漢語拼音來命名。程序中的英文單詞一般不會太復雜，用詞應當準確。例如不要把CurrentValue寫成NowValue。

標識符的長度應當符合“min-length && max-information”原則。

命名規則盡量與所采用的操作系統或開發工具的風格保持一致。　例如Windows應用程序的標識符通常采用“大小寫”混排的方式，如AddChild。

程序中不要出現僅靠大小寫區分的相似的標識符。

變量的名字應當使用“名詞”或者“形容詞＋名詞”。

盡量避免名字中出現數字編號，如Value1,Value2等，除非邏輯上的確需要編號。這是為了防止程序員偷懶，不肯為命名動腦筋而導致產生無意義的名字（因為用數字編號最省事）

指針以p開頭、

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

關鍵詞和操作符之間加適當的空格。

縮進：4個空格
3.不允許把多個短語句寫在一行中，即一行只寫一條語句。 4.函數或過程的開始、結構的定義及循環、判斷等語句中的代碼都要采用縮進風格。

編寫程序塊時‘{’和‘}’應各獨占一行并且位于同一列，同時與引用它們的語句左對齊。在函數體的開始、類的定義、結構的定義、枚舉的定義以及if、for、do、while、switch、case語句中的程序都要采用如上的縮進方式。

代碼測試

單元測試要求至少達到語句覆蓋。

清理、整理或優化后的代碼要經過審查及測試。

發現潛在的錯誤和回歸性錯誤及可能需要改進的地方

3-數據庫設計與ER圖

4-后端架構設計

基本的用戶驗證方案

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

整體的架構設計

5-確定團隊分工

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

在博客中敘述并給出相應的WBS圖

給出團隊各個成員認領的工作，列出當前團隊的TODOList
劉辰：登陸注冊、決策、文案
曾程：決策、美工、文案
嚴域俊：游戲分類、游戲編寫、文案
鄧煜坤：整合代碼、代碼規范、文案
吳恒佚：游戲分類、游戲編寫、文案

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

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

轉載于:https://www.cnblogs.com/amberR/p/10054525.html

總結

以上是生活随笔為你收集整理的团队作业--第二次的全部內容，希望文章能夠幫你解決所遇到的問題。

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