Beta：凡事預則立

• 課程名稱：軟件工程1916|W（福州大學）
• 做業要求：項目Beta衝刺）
• 團隊名稱：葫蘆娃隊
• 做業目標：盡力完成

---

團隊博客

隊員學號	隊員暱稱	博客地址
041602421	der himmel	https://www.cnblogs.com/wenghaoo
221600225	wuliaoBoring	https://www.cnblogs.com/wuliaoBoring/
221600424	BW.LIN	https://www.cnblogs.com/lbwblog/
221600432	QZY	https://www.cnblogs.com/nuomituanzi/ 組長
221600440	小冰	https://www.cnblogs.com/xiaobing666/ 轉入
221600434	北風5620	https://www.cnblogs.com/beifeng5620/
221600435	XBN	https://www.cnblogs.com/xbnhhh/

---

一、討論組長是否重選的議題和結論

結論否，由於項目是由組長提出的，相應負責更多，組長不重選但能夠放權更多給組員，能夠選出副組長

2&三、下一階段須要改進完善的功能

完善：改進關卡設計，人物武器，可玩性平衡性競技性的調整。
新增 :局域網鏈接

四、須要改進的團隊分工（針對以前的不足，須要增強和改進團隊協做和分工的地方）

分工在一開始時要充分考慮，不只是組長分配時要考慮，組員接任務是也要考慮本身是否完成有困難，分工定好了，後期若是由於某些緣由要更改就要付出至關大的代價。
測試部分：本身寫哪部份的功能，改功能測試應該基本由他本身完成，這樣寫測試能更高效和可靠也能，能明白本身寫的代碼適不適合寫測試（是否是把有必定功能代碼寫成函數分塊便於測試，代碼耦合度會不會太高）

五、須要改進的工具流程（版本控制、測試工具等）

版本控制：組員comit消息的規範要制定，要描述這次commit的工做任務。
測試工具：有必定功能代碼寫成函數分塊便於測試，代碼耦合度不該該太高，這樣便於測試。

六、衝刺的時間計劃安排

七、代碼規範

1、註釋規約（重）

• 【強制】全部的方法要完成返回值、參數、異常說明外，還必須指出該方法作什麼事情，實現什麼功能。這種描述不該該包括執行過程細節（它是怎麼作的）
• 【強制】方法內部單行註釋，在被註釋語句上方另起一行，使用//註釋。方法內部多行註釋 使用/* */註釋，注意與代碼對齊。
• 【推薦】與其「半吊子」英文來註釋，不如用中文註釋把問題說清楚。專有名詞與關鍵字保持英文原文便可。
  反例：「TCP鏈接超時」解釋成「傳輸控制協議鏈接超時」，理解反而費腦筋。
• 【推薦】代碼修改的同時，註釋也要進行相應的修改，尤爲是參數、返回值、異常、核心邏輯等的修改。
  說明：代碼與註釋更新不一樣步，就像路網與導航軟件更新不一樣步同樣，若是導航軟件嚴重滯後，就失去了導航的意義。

• 【參考】謹慎註釋掉代碼。在上方詳細說明，而不是簡單地註釋掉。若是無用，則刪除。

• 說明：代碼被註釋掉有兩種可能性：
  • 後續會恢復此段代碼邏輯。
  • 永久不用。
  • 前者若是沒有備註信息，難以知曉註釋動機。後者建議直接刪掉（代碼倉庫保存了歷史代碼）。

2、命名風格

• 【強制】代碼中的命名嚴禁使用拼音與英文混合的方式，更不容許直接使用中文的方式。
  • 說明：正確的英文拼寫和語法可讓閱讀者易於理解，避免歧義。注意，即便純拼音命名方式也要避免採用。國際通用的名稱，可視同英文。
  • 反例：
    • DaZhePromotion [打折] 。
    • getPingfenByName() [評分] 。
    • int 某變量 = 3。
• 【強制】方法名、成員變量、類名使用 UpperCamelCase 風格，但如下情形例外：DO / BO / DTO / VO / AO / PO / UID 等。
  • 正例：MarcoPolo / UserDO / XmlService / TcpUdpDeal / TaPromotion
  • 反例：macroPolo / UserDo / XMLService / TCPUDPDeal / TAPromotion
• 【強制】參數名、局部變量都統一使用 lowerCamelCase 風格，必須聽從駝峯形式。
  • 正例： localValue / getHttpMessage() / inputUserId
• 【強制】常量命名所有大寫，單詞間用下劃線隔開，力求語義表達完整清楚，不要嫌名字長。
  • 正例：MAX_STOCK_COUNT反例：MAX_COUNT
• 【強制】抽象類命名使用 Abstract 或 Base 開頭；異常類命名使用 Exception 結尾；測試類 命名以它要測試的類的名稱開始，以 Test 結尾。
• 【強制】杜絕徹底不規範的縮寫，避免望文不知義。反例：AbstractClass「縮寫」命名成AbsClass；condition「縮寫」命名成 condi，此類隨 意縮寫嚴重下降了代碼的可閱讀性。
• 【推薦】爲了達到代碼自解釋的目標，任何自定義編程元素在命名時，使用盡可能完整的單詞組合來表達其意。
  • 正例：在 JDK 中，表達原子更新的類名爲：AtomicReferenceFieldUpdater。
  • 反例：變量 int a 的隨意命名方式。