團隊作業（三）：确定分工

一、閱讀目錄：

修改完善上周送出的需求規格說明書
團隊的編碼規範
使用Powerdesigner繪制ER圖
進行項目的後端架構設計。
團隊分工
本次分工及工作量比例
參考資料彙總

二、修改完善上周送出的需求規格說明書

上次制定的需求規格說明書中指定的部分内容實作起來較為困難，經過修改完善，我們删除了部分子產品。
修改産品功能和驗收标準、細化界面描述、完善産品說明

三、讨論制定團隊的編碼規範

代碼規範：包括代碼風格規範和代碼設計規範
代碼風格規範代碼風格的原則是：簡單，易讀，無二義性。采取何種代碼規範要看這種代碼規範能否讓程式員更好的了解和維護程式。

代碼風格規範具體包括以下幾點：

縮進。推薦使用四個空格進行縮進，最好在編輯器中将Tab鍵定義為四個空格，這樣可以避免Tab鍵在不同情況下顯示不同的問題，并使程式有良好的閱讀體驗。
行寬。最好對行寬作出限制，按照現代普遍使用的螢幕尺寸，可以考慮将行寬限制為100個字元。
括号。在複雜的表達式中，使用括号表示邏輯優先級。
斷行與空白的｛｝行。推薦每個｛和｝都單獨占一行。
分行。不要把多條語句放在一行上，更嚴格的說不要把多個變量定義在一行上。
命名。命名要注意幾條關鍵原則，簡單來說就是確定包含必要資訊，避免過多的描述。
下劃線。下劃線用來分隔變量名字中的作用于标注和變量的語義。
大小寫。通用的做法是，類型、類、函數名多有單詞的第一個字母都大寫，變量名第一個單詞全部小寫，其他單詞首字母大寫。
注釋。複雜的注釋放在函數頭，不做不必要的注釋，注釋中應隻使用ASCII字元。

代碼設計規範代碼設計規範不隻是程式書寫格式的問題，而且牽涉到程式的設計、子產品之間的關系、設計模式等方方面面。這裡主要讨論通用的原則。

函數。關于函數，最重要的一條原則就是：隻做一件事，并且要做好。
goto。函數最好有單一的出口，為了達到這一目的，可以使用goto。
錯誤處理。首先要驗證參數的正确性，當認為一件事肯定如何時，可以使用斷言。
處理c++中的類。使用類來封裝面向對象的概念和多态；避免傳遞類型實體的值，而用指針傳遞，也就是說簡單的資料類型沒有必要用類來實作；對于有顯示構造和析構的類，不要建立全局的實體。
類還是結構體。如果隻是資料的封裝，用結構體即可。
按照這樣的順序來說明類中的成員：public、protected、private。
資料成員。資料類型的成員用m_name說明；不使用公共的資料成員，要用inline通路函數，這樣可兼顧封裝和效率。
虛函數。使用虛函數來實作多态；盡在很有必要時使用虛函數；如果一個類型要實作多态，在基類中的析構函數應該是虛函數。
構造函數。不要再構造函數中做複雜的操作，簡單初始化資料稱成員即可；構造函數不應傳回錯誤，把可能出錯的操作放到HrInit（）或FInite（）中。
析構函數。把所有的清理工作放在析構函數中；同時析構函數也不應出錯。
new和delete。實作自己的new/delete可以友善地加上自己的跟蹤和管理機制；檢查new的傳回值；釋放指針時不用檢查NULL。
運算符。運算符不要做标準語義外的任何操作；運算符的實作應非常高效，如果操作複雜，定義一個單獨的函數，如果拿不定主意，用成員函數而不要用運算符。
異常。異常不能跨過DLL或程序的邊界來傳遞資訊。
類型繼承。僅在必要時使用類型繼承；用const标注隻讀的參數；用const标注不改變資料的函數。

代碼複審

①形式：自我複審、同伴複審、團隊複審

②目的：找出代碼錯誤、發現邏輯錯誤、發現算法錯誤、發現潛在的錯誤和回歸性錯誤、發現可能需要改進的地方、傳授經驗

③代碼複審後把記錄整理出來：

（1）更正明顯的錯誤

（2）記錄無法很快更正的錯誤

（3）把所有的錯誤記在自己的一個“我常犯的錯誤”表中，作為以後自我複審的第一步

結對程式設計

①角色：

駕駛員：控制鍵盤輸入

領航員：起到領航、提醒的作用

②好處：

在開發層次，可以提供更好的設計品質和代碼品質，兩人合作解決問題的能力更強。

對開發人員，帶來更多的信心，高品質的産出帶來更高的滿足感。

企業管理層次上，有效地交流，互相學習和傳遞經驗，分享知識，取得更高的投入産出比。

四、使用Powerdesigner繪制ER圖

五、進行項目的後端架構設計。

六、團隊分工

利用象限法确定各個核心需求的優先級，依據需求優先級确定團隊Alpha 版本需要實作的功能，在部落格中叙述并給出相應的WBS圖。

團隊作業（三）：确定分工

2. 在團隊管理軟體中（比如Github的Issue，Leangoo等）将各個葉子結點的功能加入，并确定每個子功能的工作量，

3. 團隊各個成員（用學号代替姓名)認領的工作

七、本次分工及工作比例

主編寫人及工作負責人：施羿，王予涵，雷清逸，商蘇赫，徐彙仁