《團隊做業第二週》五小福團隊做業——UNO

《團隊做業第二週》五小福團隊做業——UNO

1、修改完善上週提交的需求規格說明書

• THE FIRST改變
• 首先：咱們組的博客無小組分工及佔比，這是第一個問題，當時咱們在寫博客的時候因爲不少問題都在討論籌備當中，所以，在寫博客的時候並無及時的添加小組分工及佔比。後來當咱們將初步工做所有完成後以後咱們在博客中補充了該內容。
  咱們小組的分工佔好比下：

成員	分工	佔比
郭愷	界面設計，原型設計需求分析，代碼初步設計	20%
段志軒	用例圖設計，代碼設計和部分編寫	20%
李馨雨	博客和需求說明書的撰寫，功能說明圖	20%
王文彬	主要幾種方法代碼的編寫	20%
李楠	用例圖設計，界面設計	20%

• THE SECOND改變

• 其次：咱們組在提交的時候並無給出用例圖。由於咱們剛開始的時候並不知道用例圖的做用，覺得它和咱們以前作的功能介紹圖同樣，後來在看了劉偉康學長的博客以後才知道用例圖也須要給出，咱們小組在通過討論以後瞭解到了用例圖是指由參與者（Actor）、用例（Use Case），邊界以及它們之間的關係構成的用於描述系統功能的視圖。用例圖（User Case）是外部用戶（被稱爲參與者）所能觀察到的系統功能的模型圖。用例圖是系統的藍圖。用例圖呈現了一些參與者，一些用例，以及它們之間的關係，主要用於對系統、子系統或類的功能行爲進行建模。對於瞭解咱們的軟件有很大的做用。
  小組用例圖以下：
  

• Markdown連接

• pdf連接

2、團隊的編碼規範

一、 標識符命名規範

1.一、命名約定

儘可能使用完整的英文描述符,採用適用於相關領域的術語;

要採用大小寫混合使名字可讀;儘可能少用縮寫，但若是用了，要明智地使用，且在整個工程中統一；

避免使用長的名字（最好小於15個字母）；避免使用相似的名字，或者僅僅是大小寫不一樣的名字。

1.二、具體用例

• 包（Package）

  採用完整的英文描述符，應該都是由小寫字母組成。

• 類（Class）

  採用完整的英文描述符，全部單詞的第一個字母大寫。 如：Card、Robot等

• 接口（Interface）

  採用完整的英文描述符來講明接口封裝，全部單詞的第一個字母大寫。習慣上，名字後面加上後綴 able，ible或者er，但這不是必需的。如：Contactable、Prompter。

• 組件/部件（Component）

  使用完整的英文描述來講明組件的用途，末端應接上組件類型。 如：startButton、fileMenu

• 類變量

  字段採用完整的英文描述，第一個字母小寫，任何中間單詞的首字大寫，如： firstName
、lastName

• 實參/參數

  同字段/屬性的命名規則

public void setFirstName(String firstName)
    {
            this.firstName = firstName;
     }

• 獲取成員函數

  被訪問字段名的前面加上前綴get。例如：getFirstName(), getLastName().

• 設置成員函數

  被訪問字段名的前面加上前綴 set。例如： setFirstName(), setLastName(),setWarpSpeed()

• 方法名

  首字母小寫，如 addOrder() 不要 AddOrder()
動詞在前，如 addOrder()，不要orderAdd()
動詞前綴每每表達特定的含義。

• 靜態常量字段（static final）

  所有采用大寫字母，單詞之間用下劃線分隔。 MIN_BALANCE, DEFAULT_DATE

• 循環計數器

  一般採用字母 i，j，k 或者 counter 均可以接受。 i, j, k, counter

• 數組（Array）

  數組應該老是用下面的方式來命名：
byte[] buffer;

二、代碼格式

2.一、 源文件編碼

源文件使用utf-8編碼。

2.二、行寬

行寬度不要超過130。

2.三、包的導入

刪除不用的導入，儘可能不要使用整個包的導入。

2.四、代碼塊格式

2.4.一、縮進風格

大括號的開始要在代碼塊開始的下一行的行頭，閉合在和代碼塊同一縮進的行首，例如：

public class TestStyle extends SomeClass implements AppleInter, BananaInter 
{
  public static final String THIS_IS_CONST = "CONST VALUE";

  private static void main(String[] args) 
  {
      int localVariable = 0;
  }

  public void compute(String arg) 
  {
    if (arg.length() > 0) 
    {
       System.out.println(arg);
    }

    for (int i = 0; i < 10; i++) 
    {
      System.out.println(arg);
    }
  }    
}

2.4.二、空格的使用

• 二元三元運算符兩邊用一個空格隔開
  以下：

a + b = c;
b - d = e;
return a == b ? 1 : 0;

  不能以下：

a+b=c;
b-d=e;
return a==b?1:0;

• 逗號語句後如不換行，緊跟一個空格
  如：call(a, b, c);
  不能如：call(a,b,c);

  2.4.三、空行的使用

  緣由：空行能夠表達代碼在語義上的分割，註釋的做用範圍，超過十行的代碼若是還不用空行分割，就會增長閱讀困難將相似操做。

• 使用規則：
  • 連續兩行的空行表明更大的語義分割。
  • 方法之間用空行分割;
  • 域之間用空行分割;
• 示例：

order = orderDao.findOrderById(id);

//update properties
order.setUserName(userName);
order.setPrice(456);
order.setStatus(PAID);

orderService.updateTotalAmount(order);

session.saveOrUpdate(order);

上例中的空行，使註釋的做用域很明顯.

3.、註釋規範

3.一、 註釋代碼規範

註釋宜少而精，不宜多而濫，更不能誤導。

命名達意，結構清晰，類和方法等責任明確，每每不須要，或者只須要不多註釋，就可讓人讀懂；相反，代碼混亂，再多的註釋都不能彌補。因此，應當先在代碼自己下功夫。不要過於詳細的註釋，對顯而易見的代碼不添加註釋。

註釋要和代碼同步，過多的註釋會成爲開發的負擔;註釋不是用來管理代碼版本的，若是有代碼不要了，直接刪除，不用註釋掉，不然之後沒人知道那段註釋掉的代碼該不應刪除。

3.二、Java Doc

代表類、域和方法等的意義和用法等的註釋，要以javadoc的方式來寫。Java Doc是個類的使用者來看的，主要介紹 是什麼，怎麼用等信息。凡是類的使用者須要知道，都要用Java Doc 來寫。非Java Doc的註釋，每每是個代碼的維護者看的，着重告述讀者爲何這樣寫，如何修改，注意什麼問題等。 以下：

/** 個人數組幫助類
  *定義一個用於操做數組的工具類。
  *好比：獲取最值，排序，折半。
  *@author 張三
  *@version V1.0
  */

具體可看博客參考

• javadoc 和 javadoc註釋規範
• java文檔註釋--javadoc的用法

3.三、塊級別註釋

3.3.一、塊級別註釋

單行時用 //, 多行時用 /* .. */。

3.3.二、較短的代碼塊

用空行表示註釋做用域

3.3.三、較長的代碼塊

用/*------ start: ------*/
和
/*-------- end: -------*/包圍
如：

/*----------start: 訂單處理 ------- */
//取得dao
OrderDao dao = Factory.getDao("OrderDao");

/* 查詢訂單 */
Order order = dao.findById(456);

//更新訂單
order.setUserName("uu");
order.setPassword("pass");
order.setPrice("ddd");

orderDao.save(order);
/*----------end: 訂單處理 ------- */

3.4 行內註釋

行內註釋用 // 寫在行尾

4.選擇理由

• 首先，這樣方便軟件維護。據統計，80％的軟件開發費用在維護，規範化的代碼才方便維護，下降維護成本。
• 其次， 好的編碼規範可以大大加強代碼的可讀性，便於開發人員快速的理解新代碼。任何產品都須要好的包裝。咱們能夠把代碼自己看做是一種產品，那麼按照規範編程也是對這個「產品」的包裝 。
• 另外，規範化的代碼也是軟件質量的保證手段之一，也是軟件過程可以流暢的基礎。咱們每一個人必須緊緊樹立這樣的觀念：你今天所編寫的代碼，會一直使用不少年，而且頗有可能被其餘人維護和改進。因此，咱們必須努力寫出「乾淨」和易讀的代碼。本文檔適用於軟件開發過程當中開發人員，主要包括編碼人員、測試人員，開發人員，規範必須嚴格遵照，不然程序被視爲不合格程序。

3、團隊項目的數據庫設計及相應ER圖

因爲咱們組的數據庫較爲單純，只須要存儲用戶的姓名、帳號和密碼以及用戶在遊戲中的排名和成績，故咱們的ER圖較爲簡單。

4、項目的後端架構設計

• 咱們小組使用Xmind實現以下：
  

• 登陸界面
  首先跳出一段咱們製做的歡迎動畫，讓玩家感覺到滿滿的遊戲畫面感。
  而後進入登陸界面
  登陸界面包括兩個內容，註冊與登陸。
  若已經註冊則直接點擊登陸進入遊戲，若還沒有註冊則點擊註冊進入註冊頁面，待註冊完畢後登陸進入遊戲。
• 準備界面
  準備界面包括開始遊戲、退出遊戲、遊戲介紹。
  點擊開始遊戲便可進入下一個界面，下一個界面包括繼續上次遊戲和選擇遊戲場規模兩個選項；若選擇繼續上次遊戲就直接進入遊戲界面繼續遊戲，若單擊選擇遊戲場規模就進入對遊戲場的選擇。一共有四個遊戲場規模的選擇，分別是三人場、四人場、五人場和無限場（不對牌的數量作限制）。再經過選擇後進入遊戲場。
• 遊戲界面
  遊戲界面包括如下內容：
  （1）牌類
  該內容顯示你如今所擁有的全部手牌，以及不一樣分類，還有其餘玩家的手牌個數，牌堆剩餘個數。
  （2）功能按鈕類
• 一鍵整理按鈕：能夠整理你的手牌
• 選色按鈕：爲下一家指定顏色。
• 出牌按鈕：選定你選擇的牌並點擊出牌，如果知足遊戲規則就正常出牌，如果不知足就報錯給玩家。
• 菜單欄
  • 存檔：保存當前遊戲，下次可在準備界面中選擇繼續遊戲。
  • 音樂選擇：能夠選擇打開或者關閉
  • 重來：從新開局
  • 退出：直接退回開始的主界面。

5、團隊分工

成員	分工
郭愷	負責有關Android界面設計
段志軒	負責Android數據庫，存放用戶名、密碼、用戶分數
李馨雨	代碼規範，後端設計，學習動畫設計
王文彬	設計紙牌還有牌類完善
李楠	整理博客，學習Android數據庫

【注】個別成員在沒有具體工做時會進行動態分配。

• 利用象限法肯定各個核心需求的優先級：
  
• 功能介紹圖（WBS）：
  

6、TODOList及燃盡圖

• TODOList的項目添加
  
• 碼雲上的Issue：
  
• github上的Issue：
  
• 燃盡圖：（僅本週任務）
  
  

7、本次分工及工做量比例

成員	我的貢獻及完成度	佔比
郭愷	界面的製做，學習了github完成燃盡圖	20%
段志軒	經過Powerdesigner完成團隊項目的數據庫設計，並在隨筆中提供了相應ER圖。	20%
李馨雨	進行項目的後端架構設計 ，制定團隊的編碼規範，添加了issues	20%
王文彬	編寫代碼，肯定每一個子功能的工做量	20%
李楠	整理博客，利用象限法肯定各個核心需求的優先級	20%

8、本週小組會議及交互總結

  本週的共同窗習時間太少，討論時間不夠，你們作事效率比較低，總體氛圍有待緩衝提升。

  在本週，咱們小組共同肯定了任務方向、制定了工做計劃和任務。代碼方面王文彬同窗較好的完成了本身的工做，將bug整改了；李馨雨同窗也學習了XMIND來完成了後端設計並制定了團隊的編碼規範，郭愷同窗也着手部分界面設計和AS學習，段志軒同窗也完成了本身負責的數據庫方面，李楠同窗作了象限圖、用例圖和博客的整理。

  下一週咱們將投入更多時間去攻堅克難，但願全部小夥伴們不要掉以輕心，多多作好本身份內的工做，互幫互助，努力寫好小組項目的新篇章！

參考資料彙總

• [Java和Android開發學習指南]（第二版）
• 使用Github生成燃盡圖
• 分而治之（Work Breakdown Structure, WBS）
• xmind新手入門教程
• ER圖的繪製