201771030121-王國偉 實驗三 結對項目—《西北師範大學疫情防控信息系統》項目報告
| 項目 | 內容 |
|---|---|
| 課程班級博客鏈接 | https://edu.cnblogs.com/campus/xbsf/nwnu2020SE |
| 本次作業要求鏈接 | https://www.cnblogs.com/nwnu-daizh/p/12521474.html |
| 我的課程學習目標 | 接觸結對編程，運用結對編程 |
| 這個作業在哪些方面幫助我實現學習目標 | 實踐中認識到問題，再去解決問題的過程 |
| 結對方學號-姓名 | 201771030129-張琳 |
| 結對方本次博客作業鏈接 | https://www.cnblogs.com/zlin-/ |
| 項目Github的倉庫鏈接地址 | https://github.com/18215128518wgw/diseaseManage |
1. 實驗目的與要求
（1）體驗軟件項目開發中的兩人合作，練習結對編程（Pair programming）。
（2）掌握Github協作開發程序的操作方法。
2.實驗內容和步驟
任務1：閱讀《現代軟件工程—構建之法》第3-4章內容，理解並掌握代碼風格規範、代碼設計規範、代碼複審、結對編程概念；
- 代碼風格規範：原則：簡明，易讀，無二義性
- 代碼設計規範：代碼設計規範不光是程序書寫的格式問題,而且牽涉到程序設計、模塊之間的關係、設計模式等方方面面,這裏又有不少內容與具體程序設計語言息息相關（如C、C++、Java、C#）
- 代碼複審：看代碼是否在代碼規範的框架內正確的解決了問題，其目的在於找出代碼錯誤、發現邏輯錯誤、發現算法錯誤、發現潛在和迴歸錯誤以及發現需要改進的地方，還可以互相教育開發人員，共同成長
- 結對編程：結對編程是軟件開發過程中所使用的一種技術，兩名程序開發人員共享同一臺工作站。其中一個扮演駕駛者（Driver）的角色，進行代碼編寫，另一個扮演觀察員（Observer）或導航員（Navigator）的角色，對代碼進行評測。他們可以輪流編寫代碼和測試案例，還可以坐在一起交流思想，解決問題，而不會想偷懶去刷手機。
**任務2：**兩兩自由結對，對結對方《實驗二 軟件工程個人項目》的項目成果進行評價，具體要求如下：
任務3：採用兩人結對編程方式，結合我校師生疫情每日上報系統使用體驗，設計開發一款符合我校疫情防控工作需求的信息系統，使之具有以下功能
-
需求分析陳述
- 讓學校瞭解本人的健康狀況，有無感染新冠病毒，有無返校舉動等；
- 在系統中各二級部門疫情防控工作負責人可查看本部門人員疫情彙總，並提供高級查詢功能進行多屬性組合查詢和可視化統計功能；
- 互聯網是一個很好的平臺，通過這個平臺讓管理者瞭解被管理者的疫情情況；
- 需要填報的人數比較多，難以管理，所以應該可以查詢填報者和未填報者，並對未填報者及時作出提醒。
- 對於查詢結果，應該簡單直觀地反映出疫情情況。
-
軟件設計說明
- 結構設計：系統採用B/S架構，開發模型採用增量模型，軟件成爲一系列的構件，開發時逐個構件進行設計、實現、集成和測試
- 數據設計：軟件中再pojo層中聲明數據庫表的實體類，採用ArrayList存儲數據
- 接口設計：利用mybatis的通用Mapper進行數據操作，其他數據操作類都繼承通用mapper
- 過程設計：採用springboot搭建web應用
-
軟件實現及核心功能代碼展示:
- 用戶類：負責收集疫情信息。
- 管理員類：負責後臺控制登錄身份，定時填報提醒，數據操作。
-
程序運行
系統在線訪問地址：（因爲服務在我自己機器上跑，所以可能有時候服務沒有開啓）
學生疫情上報：http://kpgs.natapp1.cc
後臺疫情管理平臺：http://kpgs.natapp1.cc/user/login（密碼：123）
（1）可採集全校各類師生員工疫情信息；
![]()
（2）各二級部門疫情防控工作負責人可查看本部門人員疫情彙總，並提供高級查詢功能進行多屬性組合查詢和可視化統計功能；
![]()
![]()
（3）學校防控辦指定負責人登錄《西北師範大學疫情防控信息統計》子系統，可瀏覽所有人員填報彙總數據清單，利用【高級查詢】可進行數據組合篩選，系統以圖形化方式展示各學院已填報和未填報學生統計情況和關鍵疫情數據統計情況，可【導出】查詢列表的EXCEL文件；
![]()
![]()
（4）附加分功能：定時填報提醒
由於短信接口是網上的試用平臺，所以短信次數也有限只有10條，可能收不到驗證碼，敬請見諒
![]()
<img src="https://img2020.cnblogs.com/blog/1946356/202003/1946356-20200326231139581-1508713064.jpg" alt="" style="zoom:33%;" />
-
描述結對的過程:
-
GitHub提交截圖（建立branch，並提交）
小組在進行編程時，採用github進行代碼託管，雙方編程完成時push到GitHub上，對方要編程就可以直接用pull指令拉取最新更改，idea編輯器中，還會高亮提示改變的代碼，非常方便相互協作
![]()
-
討論截圖
![]()
![]()
![]()
-
遵守共同認可的編碼規範，增加代碼規範說明
![]()
-
-
展示PSP
| PSP | 任務內容 | 計劃共完成需要的時間(min) | 實際完成需要的時間(min) |
|---|---|---|---|
| Planning | 計劃 | 30 | 30 |
| · Estimate | 估計這個任務需要多少時間，並規劃大致工作步驟 | 30 | 30 |
| Development | 開發 | 1000 | 950 |
| · Analysis | 需求分析 (包括學習新技術) | 200 | 190 |
| · Design Spec | 生成設計文檔 | 100 | 120 |
| · Design Review | 設計複審 (和同事審覈設計文檔) | 40 | 30 |
| · Coding Standard | 代碼規範 (爲目前的開發制定合適的規範) | 60 | 60 |
| · Design | 具體設計 | 300 | 210 |
| · Coding | 具體編碼 | 300 | 200 |
| · Code Review | 代碼複審 | 100 | 60 |
| · Test | 測試（自我測試，修改代碼，提交修改） | 60 | 50 |
| Reporting | 報告 | 30 | 50 |
| · Test Report | 測試報告 | 50 | 40 |
| · Size Measurement | 計算工作量 | 30 | 20 |
| · Postmortem & Process Improvement Plan | 事後總結 ,並提出過程改進計劃 | 60 | 50 |
-
小結感受:兩人合作真的能夠帶來1+1>2的效果嗎
經過這次實驗，我發現在真正的結對的情況下，確實會產生1+1>2的情況，因爲另一方會從另外一個角度思考，發現對方代碼的不足並及時指正。但也存在雙方工作沒辦法平均分配，雙方各有擅長的方面，所以在合作時更多的是取長補短，發會合作的優勢。
<br><br><br><br>
小記
- 這次對於github的一系列操作有了很深的印象，像clone以及push，pull，branch這些通過好多次的練習肯定會牢牢記住的
- 對於結對編程有了一定了解。