我的第三次做業——結對編程

1.編碼要求

（1）Fork github 項目https://github.com/Cherish599/PairProgramming到本身的倉庫，在Github倉庫中新建一個以一位同窗的學號爲名的文件夾，用於創建C#的項目和第二次做業相似。（結對的兩人中任意一人的學號均可以）。
（2）在開始實現程序以前，在PSP表格[附錄1]記錄下你估計在程序開發各個步驟上耗費的時間，在你實現程序以後，在PSP表格記錄下你在程序的各個模塊上實際花費的時間。
（3）使用C#語言實現，C#請使用Visual Studio Community 2017進行開發。

• a) 制定編碼規範，能夠參考C#語言的規範：簡版，討論版。（鄒欣老師在講義「現代軟件工程講義 3 代碼規範與代碼複審」中所討論的有關代碼規範與代碼複審的內容。內容短小精煉，適合快速入門。）
• b) 代碼自審並修正，每一個人都獨立完成了本身的功能任務，對照編碼規範，審查修改本身的程序代碼並使其符合規範要求。
• c) 代碼互審，按照共同制定的編碼規範，審查合做夥伴的代碼並記錄發現的問題。
• d) 合併代碼，兩人協商，將兩部分代碼合併，造成初始版本。注意應設計合理的軟件結構及模塊劃分。
• e) 使用Github[附錄2]來管理源代碼和測試用例，代碼有進展即簽入Github（至少三次）。簽入記錄不合理的項目會被助教抽查詢問項目細節。
• f) 使用單元測試[附錄3]對項目進行測試，並寫出測試用例確保你的程序可以正確處理的各類狀況。
• g) 在完成結對項目後，請按照預第二次做業的方式正確地發起一個Pull Request，並設置標題爲本次統一使用的學號。

2.博客撰寫要求

（1）在文章開頭給出結對使用的Github項目地址和結對夥伴的做業地址。（兩我的使用同一個）注意：GitHub的地址必須是用於clone的地址即以下圖片中的地方獲取。（若是不是這個地址，助教就沒法批量編譯運行大家的程序，出現問題的都會被助教抽中詢問詳情）

描述結對的過程，提供非擺拍的兩人在討論的結對照片（一塊兒工做編碼時的照片）。
（3）給出結對的PSP表格。

• a) 解題思路描述。即剛開始拿到題目後，如何思考，如何找資料的過程。
• b) 設計實現過程。設計包括代碼如何組織，好比會有幾個類，幾個函數，他們之間關係如何，關鍵函數是否須要畫出流程圖？單元測試是怎麼設計的？
• c) 給出大家制定的代碼規範或連接，記錄大家代碼互審的狀況，審查的模塊名、發現的問題等。
• d) 代碼說明。展現出項目關鍵代碼，並解釋思路與註釋說明。
• e) 結合在構建之法中學習到的相關內容與結對項目的實踐經歷，撰寫解決項目的心路歷程與收穫，以及結對感覺，是否1+1>2。

注：兩人都要提交博客，結對共同部分，可在其中一我的的博客給出（另外一我的給出連接），不一樣部分分別寫在本身的博客中。

3.項目需求說明

實現一個WinForm隨機點名的程序或者骰子游戲

第一步、實現基本功能

• 一、winform界面設計

• 二、實現班級學生的隨機點名

  第二步、接口封裝

• 一、體現類的設計

• 二、體現分層思想

第三步、增長新功能

• 一、學生數據的加載
• 二、進度條跟蹤

第四步、附加功能

• 一、小組的創新性功能設計

第五步、設計單元測試

• 請各位使用單元測試對項目進行測試。 並給出測試用例

4.評分細則

博客評分規則（總分100）

（1） 在文章開頭給出大家Fork倉庫的Github項目地址。（5'）
（2） 在開始實現程序以前，在下述PSP表格記錄下你估計將在程序的各個模塊的開發上耗費的時間。（5'）
（3） 計算模塊接口的設計與實現過程。 設計包括代碼如何組織，好比會有幾個類，幾個函數，他們之間關係如何，關鍵函數是否須要畫出流程圖？說明你的算法的關鍵（沒必要列出源代碼），以及獨到之處。並講講你的設計是如何體現「Design by Contract」、「Information Hiding」、 「Interface Design」、 「Loose Coupling」等原則的。（45）
（4） 代碼複審過程。代碼互審狀況、發現的問題等。（15‘）
（5） 計算模塊部分單元測試展現。 展現出項目部分單元測試代碼，並說明測試的函數，構造測試數據的思路。並將單元測試獲得的測試覆蓋率截圖，發表在博客中。（15'）
（6） 描述結對的過程，提供非擺拍的兩人在討論的結對照片。（5'）
（7） 在你實現完程序以後，在附錄提供的PSP表格記錄下你在程序的各個模塊上實際花費的時間。（5'）
（8） 附加功能（5）

五、附錄

一、PSP表格

PSP是卡耐基梅隆大學（CMU）的專家們針對軟件工程師所提出的一套模型：Personal Software Process (PSP， 我的開發流程，或稱個體軟件過程)。

PSP2.1	Personal Software Process Stages	預估耗時（分鐘）	實際耗時（分鐘）
Planning	計劃
· Estimate	· 估計這個任務須要多少時間
Development	開發
· Analysis	· 需求分析 (包括學習新技術)
· Design Spec	· 生成設計文檔
· Design Review	· 設計複審 (和同事審覈設計文檔)
· Coding Standard	· 代碼規範 (爲目前的開發制定合適的規範)
· Design	· 具體設計
· Coding	· 具體編碼
· Code Review	· 代碼複審
· Test	· 測試（自我測試，修改代碼，提交修改）
Reporting	報告
· Test Report	· 測試報告
· Size Measurement	· 計算工做量
· Postmortem & Process Improvement Plan	· 過後總結, 並提出過程改進計劃
	合計

• 一個功能完備的程序不是一蹴而就的。經過將WinForm隨機點名的程序或者骰子游戲的需求劃分爲4個部分，可將一個大任務劃分爲可操做的小任務，同時最好按照任務難度或緊急程度指定各個任務的完成次序。所以，在動手開發以前，要先估計將在程序各模塊開發所需耗費的時間，以及完成整個項目所需的時間，將這個[估計值]記錄下來，寫成PSP 的形式。
• PSP的目的是：記錄工程師如何實現需求的效率，和咱們使用項目管理工具（例如微軟的Project Professional，或者禪道等）進行項目進度規劃相似。
• 有關PSP的更多內容，請自行閱讀鄒欣老師的博客：
  http://www.cnblogs.com/xinz/archive/2011/10/22/2220872.html

二、 Github

請閱讀鄒欣老師的博客：源代碼管理，瞭解源代碼管理的10個實踐問題。
本次做業要求使用Github進行源代碼管理，代碼有進展即簽入Github。簽入記錄不合理的項目會被助教抽查詢問項目細節。
對代碼簽入的具體要求以下：根據需求劃分功能後，每作完一個功能，編譯成功後，應至少commit一次。本例中，至少應區分基本功能和擴展功能，即分別針對基本功能、擴展功能，編譯成功後，總共至少應commit兩次。具體的功能劃分，請自行定義，並在撰寫博客時體現出來，遵循本身對需求的功能劃分來提交代碼便可。
對Commit不是很熟悉的話，請閱讀阮一峯的博客：Commit message 和 Change log 編寫指南，瞭解更多細節。

三、單元測試

請根據本身以往積累的測試經驗，在編碼完成以後，提交產品以前，設計測試用例，並編寫單元測試，對本身的項目進行測試。
首先，至少應採用白盒測試用例設計方法來設計測試用例，其餘測試方法不限。其次，要設計至少10個測試用例，確保你的程序可以正確處理各類狀況。最後，結合測試評估的要求，對本身的測試設計進行評價，這些測試用例能知足該程序測試的要求嗎？
另外一個重要的措施是要把單元測試自動化，這樣每一個人都能很容易地運行它，而且可使單元測試天天都運行。每一個人均可以隨時在本身的機器上運行。團隊通常是在每日構建中運行單元測試的，這樣每一個單元測試的錯誤就能及時被發現並獲得修改。
推薦閱讀鄒欣老師關於單元測試和迴歸測試的博客：
http://www.cnblogs.com/xinz/archive/2011/11/20/2255830.html

六、提醒

（1）代碼不要出現抄襲或者直接拷貝的現象，一旦發現做業將沒有成績。（容許模仿，但必定要有本身的理解和改進） （2）確保代碼可以運行經過，代碼不能經過，則博客成績最多給60分。 （3）博客要體現出本身的思想，每一個人遇到的問題和解決方法以及感得到的感覺都應是不同的，博客出現抄襲或者拷貝現象，一旦發現做業將沒有成績。