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

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

1.修改完善上周送出的需求規格說明書，并在部落格中描述：上次的《需求規格說明書》初稿有哪些不足？修改需同時展現在Github的MarkDown檔案與PDF中。

2.讨論制定團隊的編碼規範，讨論之前和讨論之後，隊員閱讀《建構之法》第四章内容，并讨論總結。将代碼規範和編碼原則釋出在随筆上，并說說你們這麼選擇的理由。

3.通過Powerdesigner完成團隊項目的資料庫設計，并在随筆中提供相應ER圖。

4.進行項目的後端架構設計，要與需求規格說明書中的界面原型設計相對應。

5.确定團隊分工。請參考"分而治之(WBS - Work Breakdown Structure)"，提供下述内容：

• 利用象限法确定各個核心需求的優先級，依據需求優先級确定團隊Alpha版本需要實作的功能，在部落格中叙述并給出相應的WBS圖。
• 在團隊管理軟體中（比如Github的Issue，Leangoo等）将各個葉子結點的功能加入，并确定每個子功能的工作量，在部落格中給出配置設定後的截圖。值得注意的是，與學習技術相關的任務也需要考慮在工作量中，開發需要檢驗産出，學習同樣要有結果。PM可以用小Demo示範或學習心得部落格作為學習任務的檢驗。

• 給出團隊各個成員（用學号代替姓名）認領的工作，列出目前團隊的TODOList，并在最後給出燃盡圖。

  6.描述組員在上述任務中的分工和工作量比例。

代碼規範和編碼原則

代碼規範

代碼規範可以分成兩個部分：

• 代碼風格規範，主要是文字上的規定；
• 代碼設計規範，牽涉到程式設計、子產品之間的關系、設計模式等方方面面的通用原則。

代碼風格規範

代碼風格的原則是：簡明、易讀、無二義性。

• 縮進：将Tab鍵擴充定義為4個空格。不直接使用tab鍵的原因是它在不同的情況下會顯示不同的長度。4個空格可讀性高；
• 行寬：行寬必須限制，建議100字元；
• 括号：在複雜的條件表達式中，用括号清楚地表示邏輯優先級；
• 斷行與空白的{}行：
• 分行：不要把多中不同的操作放在同一行（書中建議“不要把多個變量定義在一行”，可能會使代碼不夠簡潔）；
• 命名：“匈牙利命名法”；
• 下劃線：分隔變量名字中的作用域标注的變量的語義；
• 大小寫：全部大寫、小寫會導緻不易讀，所有的類型/類/函數名用 Pascal 形式（每個單詞首字母大寫），所有變量都用 Camel （第一個單詞小寫，後面用 Pascal ）；
• 注釋：解釋程式做什麼，為什麼這樣做。複雜的注釋放在函數頭，解釋參數，要不斷更新（書中建議使用ASCII碼以增強可移植性，但實際操作複雜，我們不做這方面的要求）；

代碼設計規範

• 函數：隻做一件事，做好一件事；
• goto：可使用goto實作函數的單一出口（但也要盡量少使用),助于程式邏輯的清晰展現
• 錯誤處理：參數處理、斷言。在Debug版本中，所有參數都要驗證其正确性，在正式版本中，對外部轉遞就倆的參數要驗證其正确性；
• 運算符：一般情況下不需要自定義操作符，運算符不要做标準語義以外的任何動作。運算符的實作必須非常有效率，如有複雜的操作，應定義一個單獨的函數；

單一職責原則 Single Responsibility Principle

一個類或者一個接口，最好隻負責一項職責。

遵循單一職責原則。分别建立新的類來對應相應的職責；這樣就能避免修改類時影響到其他的職責。

裡氏替換原則 Liskov Substitution Principle

在使用基類的地方可以任意使用其子類，能保證子類完美替換基類；這一種精神其實是對繼承機制限制規範的展現。在父類和子類的具體實作中，嚴格控制繼承層次中的關系特征，以保證用子類替換基類時，程式行為不發生問題，且能正常進行下去。

對于繼承來說，父類定義了一系列的規範和契約，雖然不強制所有的子類必須遵從，但是如果子類對這些非抽象方法任意修改，就會對整個繼承體系造成破環。

依賴倒置原則 Dependence Inversion Principle

高層子產品不應該依賴低層子產品，二者都應該依賴其抽象；抽象不應該依賴細節；細節應該依賴抽象，其核心思想是依賴于抽象；

問題由來：類A直接依賴類B，假如要将類A改為依賴類C，則必須通過修改類A的代碼來完成；這種場景下，類A一般是高層子產品，負責複雜的業務邏輯；類B和類C是低層子產品，負責基本的原則操作；假如修改類A，會給程式帶來不必要的風險。

在實際中，我們一般需要做到以下三點：

• 低層子產品盡量都要有抽象類或者接口，或者兩者都有
• 變量的聲明類型盡量是抽象類或者接口

• 使用繼承時遵循裡氏替換原則

  解決方案：将類A修改為依賴接口I，類B和類C各自實作接口I，類A通過接口I來間接與類B和類C發生聯系，則會降低修改類A的幾率。

接口隔離原則 Interface Segregation Principle

用戶端不應該依賴它不需要的接口；一個類對另一個類的依賴應該建立在最小的接口上，否則将會造成接口污染；類A通過接口I依賴類B，類C通過接口I依賴類D，如果接口I對于類A和類B來說不是最小接口，則類B和類D必須去實作它們不需要的方法。

原則的含義是：建立單一接口，不要建立龐大臃腫的接口，盡量細化接口，接口中的方法盡量少；就是說，我們要為每個類建立專用的接口，而不要試圖去建立一個龐大的接口供所有依賴它的類去調用

如何實施接口隔離，主要有兩種方法：

• 委托分離，通過增加一個新的接口類型來委托客戶的請求，隔離客戶和接口的直接依賴，注意這同時也會增加系統的開銷；
• 多重繼承分離，通過接口的多重繼承來實作客戶的需求。

迪米特法則

一個對象應該對其他對象保持最少的了解，其核心精神就是：不和陌生人說話，通俗之意就是一個對象對自己需要耦合關聯調用的類應該知道的少；這會導緻類之間的耦合度降低，每個類都盡量減少對其他類的依賴。

合成複用原則

原則是盡量使用合成/聚合的方式，而不是使用繼承。

開閉原則

一個軟體實體如類、模版和函數應該對擴充，對修改關閉。

解決方案：當軟體需要變化時，盡量通過擴充軟體實體的行為來實作變化，而不是修改已有的代碼來實作變化。

單一職責原則：實作類要職責單一

裡氏替換原則：不要破壞繼承體系

依賴倒置原則：面向接口程式設計

接口隔離原則：設計接口的時候要精簡單一

迪米特法則：降低耦合

開閉原則：總綱，對擴充開放，對修改關閉

代碼複審

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

通過Powerdesigner完成團隊項目的資料庫設計，并在随筆中提供相應ER圖。

進行項目的後端架構設計，要與需求規格說明書中的界面原型設計相對應。

在團隊管理軟體中（比如Github的Issue，Leangoo等）将各個葉子結點的功能加入，并确定每個子功能的工作量，在部落格中給出配置設定後的截圖。值得注意的是，與學習技術相關的任務也需要考慮在工作量中，開發需要檢驗産出，學習同樣要有結果。PM可以用小Demo示範或學習心得部落格作為學習任務的檢驗。給出團隊各個成員（用學号代替姓名）認領的工作，列出目前團隊的TODOList，并在最後給出燃盡圖。

組員分工

姓名	工作
郝嘉樂	WBS圖
王秋雨	ER圖
初凱旋	項目的後端架構設計
吳泳淋	燃盡圖
馬靜怡	完善需求規格說明書、彙總讨論結果