團隊項目第一次做業

1、團隊成員介紹

成員姓名	隊內身份	負責工做
賈福巍	項目管理員	規劃項目進程、 組織討論、分配任務 博客撰寫、PPT製做
王言冬	PM	協助規劃項目進程、 參與開發、 博客撰寫、PPT製做
張九川	產品經理	選題講解、內容展現
謝曉飛	後端開發	負責後端代碼的開發
張文博	後端開發	負責後端代碼的開發、 PPT製做
張   迪	數據測試	後期數據測試
於   達	數據測試	後期數據測試
徐少華	資源管理	數據整理、記錄團隊進程
郭文傑	代碼規範	編寫代碼規範
李月卿	代碼規範	編寫代碼規範
路沛環	資源管理	數據整理、記錄團隊進程

2、團隊照片

3、團隊隊長

賈福巍

4、編程規範

1-1：程序塊要採用縮進風格編寫，縮進的空格數爲4個。

1-2：相對獨立的程序塊之間、變量說明以後必須加空行。

1-3：較長的語句（>80字符）要分紅多行書寫，長表達式要在低優先級操做符處劃分新行，操做符放在新行之首，劃分出的新行要進行適當的縮進，使排版整齊，語句可讀。

1-4：循環、判斷等語句中如有較長的表達式或語句，則要進行適應的劃分，長表達式要在低優先級操做符處劃分新行，操做符放在新行之首。

1-5：若函數或過程當中的參數較長，則要進行適當的劃分。

1-6：不容許把多個短語句寫在一行中，即一行只寫一條語句。

1-7：if、for、do、while、case、switch、default等語句自佔一行，且if、for、do、while等語句的執行語句部分不管多少都要加括號{}。

1-8：對齊只使用空格鍵，不使用TAB鍵。

1-9：函數或過程的開始、結構的定義及循環、判斷等語句中的代碼都要採用縮進風格，case語句下的狀況處理語句也要聽從語句縮進要求。

1-10：程序塊的分界符（如C/C++語言的大括號‘{’和‘}’）應各獨佔一行而且位於同一列，同時與引用它們的語句左對齊。在函數體的開始、類的定義、結構的定義、枚舉的定義以及if、for、do、while、switch、case語句中的程序都要採用如上的縮進方式。

1-11：在兩個以上的關鍵字、變量、常量進行對等操做時，它們之間的操做符以前、以後或者先後要加空格；進行非對等操做時，若是是關係密切的當即操做符（如－>），後不該加空格。一行程序以小於80字符爲宜，不要寫得過長。

2-1：通常狀況下，源程序有效註釋量必須在20％以上。

2-2：說明性文件（如頭文件.h文件、.inc文件、.def文件、編譯說明文件.cfg等）頭部應進行註釋，註釋必須列出：版權說明、版本號、生成日期、做者、內容、功能、與其它文件的關係、修改日誌等，頭文件的註釋中還應有函數功能簡要說明。

2-3：源文件頭部應進行註釋，列出：版權說明、版本號、生成日期、做者、模塊目的/功能、主要函數及其功能、修改日誌等。

2-4：邊寫代碼邊註釋，修改代碼同時修改相應的註釋，以保證註釋與代碼的一致性。再也不有用的註釋要刪除。

2-5：註釋的內容要清楚、明瞭，含義準確，防止註釋二義性。

2-6：避免在註釋中使用縮寫，特別是很是用縮寫。

2-7：註釋應與其描述的代碼相近，對代碼的註釋應放在其上方或右方（對單條語句的註釋）相鄰位置，不可放在下面，如放於上方則需與其上面的代碼用空行隔開。

2-8：對於全部有物理含義的變量、常量，若是其命名不是充分自注釋的，在聲明時都必須加以註釋，說明其物理含義。變量、常量、宏的註釋應放在其上方相鄰位置或右方。

2-9：數據結構聲明(包括數組、結構、類、枚舉等)，若是其命名不是充分自注釋的，必須加以註釋。對數據結構的註釋應放在其上方相鄰位置，不可放在下面；對結構中的每一個域的註釋放在此域的右方。

2-10：全局變量要有較詳細的註釋，包括對其功能、取值範圍、哪些函數或過程存取它以及存取時注意事項等的說明。l

 

5、兩個最喜歡的模式及其優缺點

一、功能團隊模式：具有不一樣能力的同事們平等協做共同完成一個功能

優勢：效率高，組內交流頻繁，每一個成員都能發揮最大的做用；

缺點：不存在管理與被管理的關係，每一個小組必須與其餘小組就編程規範達成一致。

二、主治醫師模式

像在手術檯上同樣，有一個主刀醫師，其餘人負責協助主刀醫師。

優勢：初衷較好，在一個軟件團隊中，有首席程序員，負責主要模塊的設計和編碼，小組其餘成員儘量從各個方面配合支持程序員的工做。

缺點：在某些層面上，這種模式會逐漸退化爲「一個學生幹活，其餘學生打醬油」。

 

6、兩個選題

學生管理系統、校園交易任務平臺