團隊做業——第二週

需求規格說明書更新

• MarkDown

• PDF

• 上週寫得需求規格說明書在這一週的實現過程當中，實際實現起來就有一些不太合理的地方，根據實際狀況咱們組及時做出了調整，在每一個頁面的功能有增有減，具體修改以下：
• 如下僅爲修改的內容
  • 對3.3.1精度部分進行過修改，緣由是在越日後的關卡，障礙物出現的速度會愈來愈快，碰撞的精度會降低。
  • 補充了目錄，方便查看內容

  • 補充了用例示意圖，以前只有表格版的，如今加上圖示更清楚。
    

  • 4.1.3界面驗收標準

    界面名稱	界面描述
    開始界面	背景圖填充，有開始遊戲、離開遊戲、排行榜、商店等按鈕
    商店界面	提供不一樣風格的跑酷角色，供玩家進行選擇跑酷
    遊戲界面(操做)	相似王者榮耀的兩端式的按鈕，在界面兩側各設置按鈕來實現跑酷角色躲避障礙物的不一樣狀態
    遊戲界面(遊戲)	跑酷角色在當前背景圖下躲避障礙物的動畫
    暫停界面	提供用戶優點暫時的離開
    加載界面	加載遊戲時避免用戶無聊而建立的部分
    通關界面	不一樣風格的跑酷風格，給用戶提供多樣的跑酷狀態

  • 4.1.4功能驗收標準

    功能名稱	操做界面	詳細介紹
    選擇標準	商店界面	點擊人物會被選擇開始遊戲
    排行	排行界面	點擊會出現最高名次
    人物動做	遊戲界面	經過遊戲界面的按鈕進行不一樣狀態的變換

  • 4.1.5遊戲檢驗標準

    功能名稱	操做界面	詳細介紹
    人物動畫	遊戲界面	可以經過按鈕令人物躲避障礙物實現跑酷
    障礙	遊戲界面	可以以必定規律進行出現
    音樂	各個界面	提供遊戲時音樂效果，能夠手動關閉
    排行	排行榜	可以查詢最高成績

團隊編碼規範

• 命名規範
  • 用全英文單詞命名的方式，準確地描述性質，使代碼容易理解。如使用printTrace而不是PT。
  • 避免命名時使用下劃線。
  • 採用大小寫混合的方式來命名，加強命名的可讀性。組成類名、變量名中的每一個單詞的首字母均大寫，其他的小寫，例如ArrayMaxHeap;方法名的第一個字母小寫，其餘單詞的首字母大寫，例如toString。
  • 儘可能避免使用單詞縮寫，對於單詞過長的不得不使用縮寫的狀況，必須使用通用縮寫方式，例如number可寫爲num而不是nu。而且在全部類中保持不變。
  • 避免太長的命名，以少於20個字符爲宜。
  • 避免兩個命名只是某些字母大小寫不同，其餘拼寫徹底相同的狀況，這樣容易形成混淆。例如SuffixExpresion和suffixexpresion。
  • 常量使用大寫拼寫並用下劃線分隔。

  • 避免使用不易理解的數字，例如：

    if  (state == 0)
    {
        state = 1;
        ... // program  code
    }

    這樣對於數字的理解，編碼人員之間可能會有不一樣的理解，應改成以下:

    private final static int  TRUNK_IDLE = 0; private final static int TRUNK_BUSY = 1; private final static int TRUNK_UNKNOWN = -1;  
    if (state == TRUNK_IDLE){     
        state = TRUNK_BUSY;     
        ... // program code
    }

  • 數組聲明的時候使用 int[] index ，而不要使用 int index[]
  • 包名統一使用小寫，點分隔符之間有且僅有一個天然語義的英語單詞。包名統一使用單數形式，可是類名若是有複數含義，類名可使用複數形式。

  • 抽象類命名使用 Abstract 或 Base 開頭； 異常類命名使用 Exception 結尾； 測試類命名以它要測試的類的名稱開始，以 Test 結尾。

• 代碼規範
  • 代碼中的{}不可省，在if語句和while語句中即便只有一行代碼也不可省。
  • 方法類型默認爲是密封的。
  • 對接口和複雜代碼塊必須進行註釋，並儘可能使用簡潔易懂的註釋代碼，避免長篇大論。
  • 在自定義異常時，必須使用提供的模板來建立自定義異常。

  • 全部的數據類必須重載toString() 方法，返回該類有意義的內容。說明：父類若是實現了比較合理的toString() ， 子類能夠繼承沒必要再重寫。例如：

    public TopoNode
    {
     private String nodeName;
     public String toString()
       {
      return "NodeName : " +  nodeName;
      }
     }

  • 拋出的異常必需要填寫詳細的描述信息,便於問題定位。例如：

    throw  new IOException("Writing data error! Data: " + data.toString());

• OPP規約
  • 當一個類有多個構造方法，或者多個同名方法，這些方法應該按順序放置在一塊兒
  • 類內方法定義順序依次是:公有方法或保護方法 > 私有方法 > getter/setter 方法。
  • final 能夠聲明類、成員變量、方法、以及本地變量，下列狀況使用 final 關鍵字:
    • 不容許被繼承的類，如:String 類。
    • 不容許修改引用的域對象，如:POJO 類的域變量。
    • 不容許被重寫的方法，如:POJO 類的 setter 方法。
    • 不容許運行過程當中從新賦值的局部變量。
    • 避免上下文重複使用一個變量，使用 final 述能夠強制從新定義一個變量，方便更好 地進行重構。
  • 類成員與方法訪問控制從嚴:
    • 若是不容許外部直接經過 new 來建立對象，那麼構造方法必須是 private。
    • 工具類不容許有 public 或 default 構造方法。
    • 類非 static 成員變量而且與子類共享，必須是 protected。
    • 類非 static 成員變量而且僅在本類使用，必須是 private。
    • 類 static 成員變量若是僅在本類使用，必須是 private。
    • 如果 static 成員變量，必須考慮是否爲 final。
    • 類成員方法只供類內部調用，必須是 private。
    • 類成員方法只對繼承類公開，那麼限制爲 protected

  • 使用索引訪問用String的split方法獲得的數組時，需作最後一個分隔符後有無內容的檢查，不然會有拋出IndexOutOfBoundsException 的風險。例如：

    String str = "a,b,c,,";
    String[] ary = str.split(","); 
    // 預期大於 3，結果是 3 
    System.out.println(ary.length);

  • Object 的equals方法容易拋空指針異常，應使用常量或肯定有值的對象來調用equals。應使用「test」.equals(object);而不是object.equals(「test」);全部的相同類型的包裝類對象之間值的比較，所有使用 equals 方法比較。

• 註釋規範
  • 修改代碼時保持註釋同步。
  • 修改他人代碼時要先註釋對方代碼，並寫明修改緣由，不容許隨便刪除他人代碼。
  • 發佈前移除無用註釋。

  • 類註釋

    /**
    * @version: V1.0
    * @author: fendo
    * @className: user
    * @packageName: user
    * @description: 這是用戶類
    * @data: 2017-07-28 12:20
    **/

  • 構造函數註釋

    **
    * @description: 構造函數
    * @param: [sid, pid]
    */

  • 方法註釋

    /**
    * @author:  fendo
    * @methodsName: addUser
    * @description: 添加一個用戶
    * @param:  xxxx
    * @return: String
    * @throws: 
    */

  • 代碼塊註釋

    /**
    * 實例化一個用戶
    * xxxxxxx
    */
    User user=new User();

  • 單句註釋

    User user=new User();  //實例化一個用戶

• 選擇理由
  • 代碼規範咱們組本身想的並不完整，考慮也不周全，具體參考了網上的一些較完善的代碼規範，編程規約之OOP規約
    ，編碼規範(一)----JAVA註釋規範
  • 首先是與咱們實際使用狀況相結合的，選擇的是在代碼編寫過程當中經常使用的而且是有必要的。
  • 第二，因爲咱們組是團隊合做完成，因此統一且易於使用的代碼規範有助於加強代碼的可讀性，促進小組成員的協做。
  • 第三，良好的代碼規範在程序出現bug時，能夠方便審查代碼查找錯誤。
  • 第四，老師之前分享過一篇文章，題目是：因不寫註釋，碼農殺了4位同事，一人狀況危急...因此，我但願咱們的小組成員可以健康快樂...

ER圖

咱們組暫未使用到數據庫，下週會使用到Android Studio自帶的數據庫，如今對其餘方面做了圖。

• 主體
  
• 動畫
  

項目後端架構設計

• 遊戲圖標是一個可愛的凸顯遊戲性質的圖片
• 主界面包括
  • 1.開始遊戲按鈕
    • 點擊進入遊戲界面開始遊戲
      • 遊戲界面有高低障礙物隨機出現，玩家能夠點擊跳躍和俯身兩個動做按鈕來躲避障礙物。
  • 排行榜按鈕
    • 點擊能夠查看歷史成績，有較好的前幾回成績記錄，並附有用戶信息。
  • 商店按鈕
    • 點擊能夠有多重人物以供玩家選擇，玩家能夠點擊本身喜歡的人物形象來遊戲，加強玩家在遊戲過程當中的體驗感。
  • 退出遊戲
    • 點擊便可退出遊戲

團隊分工

• 參考分而治之（Work Breakdown Structure, WBS）

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

• 團隊Alpha版本須要實現的功能
  • Alpha版本
    • 1.開始，退出，暫停按鈕
    • 2.遊戲界面：人物，障礙物（空中、地面），跑道
    • 3.障礙物出現，人物奔跑功能
    • 4.商店，遊戲通關/失敗功能，成績排行功能
  • β版
    • 1.商店選擇人物功能
    • 2.音樂播放功能

• Leangoo圖
  

• WBS圖
  

• 團隊各個成員認領的工做，當前團隊的TODOList，並在最後給出燃盡圖。
  • 各個成員認領的工做
    • 譚鑫：動畫實現
    • 黃宇塘：美工
    • 趙曉海：界面實現
    • 方藝雯：文案
    • 王禹涵：界面實現

  • ToDoList圖
    

  • 燃盡圖

    因爲使用Github生成燃盡圖的過程當中，到填寫網站生成圖片的那一步時，碼雲連接無效，僅支持Github，因此上週沒有生成燃盡圖。這周用到的ToDoList軟件有生成燃盡圖功能，但製做完成後發現他不是燃盡圖該有的樣子，思考以後發現應該是由於前兩週的是如今補的並設定爲任務完成，因此在當時是沒有完成的，在第一週顯示的是一個任務沒有完成，在第二週新增任務後顯示兩個任務沒有完成，今天全都設定爲完成任務因此降低爲未完成任務爲0，應該從下週開始就正常了吧。

總結會議

這周小組會議中主要談論了上週工做總結和下週安排，具體狀況以下：

• 上週譚鑫和趙曉海負責動畫的實現併成功完成任務；黃宇塘和王禹涵負責製做背景圖以及界面設計，肯定了主題而且主要頁面設計完成；方藝雯負責寫每週總結博客以及博客中要求的一切圖之類的東西。
• 下一週小組任務是實現遊戲的可以使用功能，可以選擇人物遊戲並躲避障礙物或撞上障礙物遊戲失敗，但沒有闖關等拓展功能。其次就是界面將不斷進行美化，必要時進行更換。

組員分工和工做量比例

小組分工基本不變，但相互協做，機動地變化。

人員	工做	佔比
譚鑫	初步實現部分功能	20%
黃宇塘	製做背景圖	20%
趙曉海	初步實現部分功能	20%
方藝雯	寫博客和需求說明書	20%
王禹涵	初步實現部分功能	20%

參考資料

• 使用Github生成燃盡圖
• 分而治之（Work Breakdown Structure, WBS）
• ToDoList使用介紹
• ER圖的繪製
• 編程規約之OOP規約
• 編碼規範(一)----JAVA註釋規範