團隊作業(三):確定分工


團隊作業(三):確定分工

一、閱讀目錄:

  1. 修改完善上周提交的需求規格說明書
  2. 團隊的編碼規范
  3. 使用Powerdesigner繪制ER圖
  4. 進行項目的后端架構設計。
  5. 團隊分工
  6. 本次分工及工作量比例
  7. 參考資料匯總

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

  1. 上次制定的需求規格說明書中指定的部分內容實現起來較為困難,經過修改完善,我們刪除了部分模塊。

  2. 修改產品功能和驗收標准、細化界面描述、完善產品說明

三、討論制定團隊的編碼規范

  1. 代碼規范:包括代碼風格規范和代碼設計規范
  2. 代碼風格規范代碼風格的原則是:簡單,易讀,無二義性。采取何種代碼規范要看這種代碼規范能否讓程序員更好的理解和維護程序。

代碼風格規范具體包括以下幾點:

  • 縮進。推薦使用四個空格進行縮進,最好在編輯器中將Tab鍵定義為四個空格,這樣可以避免Tab鍵在不同情況下顯示不同的問題,並使程序有良好的閱讀體驗。
  • 行寬。最好對行寬作出限制,按照現代普遍使用的屏幕尺寸,可以考慮將行寬限制為100個字符。
  • 括號。在復雜的表達式中,使用括號表示邏輯優先級。
  • 斷行與空白的{}行。推薦每個{和}都單獨占一行。
  • 分行。不要把多條語句放在一行上,更嚴格的說不要把多個變量定義在一行上。
  • 命名。命名要注意幾條關鍵原則,簡單來說就是確保包含必要信息,避免過多的描述。
  • 下划線。下划線用來分隔變量名字中的作用於標注和變量的語義。
  • 大小寫。通用的做法是,類型、類、函數名多有單詞的第一個字母都大寫,變量名第一個單詞全部小寫,其他單詞首字母大寫。
  • 注釋。復雜的注釋放在函數頭,不做不必要的注釋,注釋中應只使用ASCII字符。
  1. 代碼設計規范代碼設計規范不只是程序書寫格式的問題,而且牽涉到程序的設計、模塊之間的關系、設計模式等方方面面。這里主要討論通用的原則。
  • 函數。關於函數,最重要的一條原則就是:只做一件事,並且要做好。
  • goto。函數最好有單一的出口,為了達到這一目的,可以使用goto。
  • 錯誤處理。首先要驗證參數的正確性,當認為一件事肯定如何時,可以使用斷言。
  • 處理c++中的類。使用類來封裝面向對象的概念和多態;避免傳遞類型實體的值,而用指針傳遞,也就是說簡單的數據類型沒有必要用類來實現;對於有顯示構造和析構的類,不要創建全局的實體。
  • 類還是結構體。如果只是數據的封裝,用結構體即可。
  • 按照這樣的順序來說明類中的成員:public、protected、private。
  • 數據成員。數據類型的成員用m_name說明;不使用公共的數據成員,要用inline訪問函數,這樣可兼顧封裝和效率。
  • 虛函數。使用虛函數來實現多態;盡在很有必要時使用虛函數;如果一個類型要實現多態,在基類中的析構函數應該是虛函數。
  • 構造函數。不要再構造函數中做復雜的操作,簡單初始化數據稱成員即可;構造函數不應返回錯誤,把可能出錯的操作放到HrInit()或FInite()中。
  • 析構函數。把所有的清理工作放在析構函數中;同時析構函數也不應出錯。
  • new和delete。實現自己的new/delete可以方便地加上自己的跟蹤和管理機制;檢查new的返回值;釋放指針時不用檢查NULL。
  • 運算符。運算符不要做標准語義外的任何操作;運算符的實現應非常高效,如果操作復雜,定義一個單獨的函數,如果拿不定主意,用成員函數而不要用運算符。
  • 異常。異常不能跨過DLL或進程的邊界來傳遞信息。
  • 類型繼承。僅在必要時使用類型繼承;用const標注只讀的參數;用const標注不改變數據的函數。
  1. 代碼復審

①形式:自我復審、同伴復審、團隊復審
②目的:找出代碼錯誤、發現邏輯錯誤、發現算法錯誤、發現潛在的錯誤和回歸性錯誤、發現可能需要改進的地方、傳授經驗
③代碼復審后把記錄整理出來:
(1)更正明顯的錯誤
(2)記錄無法很快更正的錯誤
(3)把所有的錯誤記在自己的一個“我常犯的錯誤”表中,作為以后自我復審的第一步

  1. 結對編程

①角色:
駕駛員:控制鍵盤輸入
領航員:起到領航、提醒的作用
②好處:

  • 在開發層次,可以提供更好的設計質量和代碼質量,兩人合作解決問題的能力更強。
  • 對開發人員,帶來更多的信心,高質量的產出帶來更高的滿足感。
  • 企業管理層次上,有效地交流,相互學習和傳遞經驗,分享知識,取得更高的投入產出比。

四、使用Powerdesigner繪制ER圖

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

六、團隊分工

  1. 利用象限法確定各個核心需求的優先級,依據需求優先級確定團隊Alpha 版本需要實現的功能,在博客中敘述並給出相應的WBS圖。


2. 在團隊管理軟件中(比如Github的Issue,Leangoo等)將各個葉子結點的功能加入,並確定每個子功能的工作量,
3. 團隊各個成員(用學號代替姓名)認領的工作

七、本次分工及工作比例

主編寫人及工作負責人:施羿,王予涵,雷清逸,商蘇赫,徐匯仁


免責聲明!

本站轉載的文章為個人學習借鑒使用,本站對版權不負任何法律責任。如果侵犯了您的隱私權益,請聯系本站郵箱yoyou2525@163.com刪除。



 
粵ICP備18138465號   © 2018-2025 CODEPRJ.COM