日常6+1—團隊Github實戰訓練

團隊作業第二次—團隊Github實戰訓練

第一部分

組員職責分工

前端：

• 221701104(潘晨宇):負責前端編寫，頁面跳轉，前后端接口與界面對接。
• 221701132(0):負責前端頁面的編寫跳轉，博客撰寫
• 111700516(linyyyyyyy):負責前端頁面的編寫跳轉，博客撰寫

后端：

• 221701141(馬科學):后端代碼,判斷前三次是否有成功預約以及編寫測試數據和數據庫
• 091700403(DorisDream):負責中簽處理類，數據庫sql編寫
• 221701116(暮笑):負責后端函數編寫，前后端頁面對接。
• 221701105(邵研):后端

github 的提交日志截圖&統計各組員的commit次數

• 221701141(馬科學):4次
  

• 091700403(DorisDream):6次
  

• 221701116(暮笑):11次
  

• 221701105(邵研):5次
  

• 221701104(潘晨宇):5次
  

• 221701132(0):4次
  

• 111700516(linyyyyyyy):4次
  

• master
  
  

程序運行截圖 運行環境和GUI截圖

使用說明

（realease1.0.0的版本由於后期導入包的時候分成了兩個包而未互相導入而無法正常使用，1.0.5版本重新整理了包的順序）

java程序

編譯器：eclipse

JDK：1.8.0_201

mySQL版本：8.0

引用jar包：mysql-connector-java-8.0.16.jar

數據庫名：mask，用戶名：root，密碼：cy990814（信息可在DBUtil中修改）

在eclipse中打開解壓后的文件中，找到src/front/mainWindow.java文件，運行即可

1、運行mainWindow.java，出現界面如下圖

2、輸入設置口罩總量，后按回車鍵

3、點擊開始預約

4、點擊口罩預約

5、輸入正確信息后提交

6、結束預約

7、查詢中簽

![查詢中簽](

8、輸入正確信息后，點擊確認查詢

基礎功能實現

• 口罩預約定時開放
• 開放預約后，市民可以進行登記；登記內容包括①真實姓名；②身份證號；③手機號；④預約口罩數量（如果中簽，想要買幾個口罩）
• 如果手機號或者身份證號在此前三次預約中成功中簽，預約失敗
• 否則預約成功，給出不重復的預約編號
• 預約定時關閉
• 預約頁面提供兩個按鈕，作用分別是開始預約和結束預約；
• 為方便測試，請在預約頁面提供設置口罩總量的方法
• 登記時單個用戶最高可預約口罩數量，默認為3個

附加功能實現

無

有想法且有用的功能

無

用戶體驗，操作的方便、快捷性

通過按鈕點擊直接顯示

遇到的困難及解決方法

221701104(潘晨宇):

• 遇到的困難：不同的前端開發IDE開發出來的程序可能會出現不兼容的狀態，導致相互的文件內容無法相互融合。
• 解決的辦法：在編碼之前先統一開發環境，然后再進行開發。

221701132(0):

• 遇到的困難：學習如何利用java可視化編程以及遇到的一些界面設計問題
• 解決的方法：網上查詢資料和教程以及和同組成員溝通確定

111700516(linyyyyyyy):

• 你遇到的困難：學習如何利用java可視化編程以及完善代碼（頁面跳轉和事件監聽器設計）
• 解決的方法：網上查詢資料和教程以及和同組成員溝通確定

221701141(馬科學):

• 遇到的困難:在設計數據庫的表和類圖，其他還有測試數據的生成及判斷前三次預約是否有成功記錄的部分。在設計數據庫表格的過程中，我錯誤理解了需求，認為前三次預約指的是用戶本人預約記錄的前三次，事實是發放的前三次。這樣自己設計的表格就不適用了。
• 解決的辦法:后來小組討論決定用中簽表和預約表實現這個項目，讓我不解的是每次預約都要新建這兩種表格，我總是想着兩個表格記錄所有信息，emmm。判斷前三次是否有成功預約的記錄，實際上只需要查看最近的三個中簽表是否有用戶的記錄就可以了。但由於對界面和鏈接不太熟悉，僅做出了判斷的代碼。測試數據用到了身份證號生成器，最終確定十組測試數據，基本滿足需要。

091700403(DorisDream)

• 遇到的困難：中簽處理的過程中，在處理抽簽函數隨機抽取那一塊，用random函數不可避免會出現重復抽取，於是就想每次都要去判斷前面幾次有沒有抽過這個id，這樣處理起來會不會很麻煩。
• 解決的辦法：后來想到了利用HashSet集合中元素不可重復的原則，用HashSet去存取，極大地簡化了代碼的制作流程

221701116(暮笑)

• 遇到的困難：測試處理的時候前后端對接會出現很多的問題，比如回調不正確，入參不正確。
• 解決的辦法：積極與小組成員進行溝通。
  221701105(邵研)
• 遇到的困難：ide與GitHub desktop結合的不熟練，切換分支時清空了本地代碼
• 解決的方法: Github的學習有待加強x

評估每位組員的貢獻比例，總分100

學號	貢獻度
221701104	14
221701141	12
221701132	12
111700516	13
091700403	18
221701116	18
221701105	13

PSP表格

221701132(0)

PSP2.1	Personal Software Process Stages	預估耗時（分鍾）	實際耗時（分鍾）
Planning	計划	10	15
Estimate	估計這個任務需要多少時間	8	15
Development	開發	240	220
Analysis	需求分析 (包括學習新技術)	20	40
Design Spec	生成設計文檔	30	30
Design Review	設計復審	10	10
Coding Standard	代碼規范 (為目前的開發制定合適的規范)	10	8
Design	具體設計	60	120
Coding	具體編碼	300	240
Code Review	代碼復審	60	90
Test	測試（自我測試，修改代碼，提交修改）	30	30
Reporting	報告	60	45
Test Repor	測試報告	30	30
Size Measurement	計算工作量	20	10
Postmortem & Process Improvement Plan	事后總結, 並提出過程改進計划	30	50
合計	707	633

111700516(linyyyyyyy)

PSP2.1	Personal Software Process Stages	預估耗時（分鍾）	實際耗時（分鍾）
Planning	計划	5	10
Estimate	估計這個任務需要多少時間	2	3
Development	開發	240	220
Analysis	需求分析 (包括學習新技術)	20	40
Design Spec	生成設計文檔	30	30
Design Review	設計復審	10	10
Coding Standard	代碼規范 (為目前的開發制定合適的規范)	10	8
Design	具體設計	60	120
Coding	具體編碼	300	240
Code Review	代碼復審	60	90
Test	測試（自我測試，修改代碼，提交修改）	30	30
Reporting	報告	60	45
Test Repor	測試報告	30	30
Size Measurement	計算工作量	20	10
Postmortem & Process Improvement Plan	事后總結, 並提出過程改進計划	30	50
合計	680	700

221701141(馬科學)

PSP2.1	Personal Software Process Stages	預估耗時（分鍾）	實際耗時（分鍾）
Planning	計划	10	8
Estimate	估計這個任務需要多少時間	10	8
Development	開發	295	270
Analysis	需求分析 (包括學習新技術)	30	25
Design Spec	生成設計文檔	20	10
Design Review	設計復審	15	25
Design	具體設計	60	100
Coding	具體編碼	120	70
Code Review	代碼復審	20	15
Test	測試（自我測試，修改原型，優化）	30	25
Reporting	報告	60	46
Test Report	測試報告	20	15
Size Measurement	計算工作量	10	6
Postmortem & Process Improvement Plan	事后總結, 並提出過程改進計划	30	25
	合計	365	324

091700403(DorisDream)

PSP2.1	Personal Software Process Stages	預估耗時（分鍾）	實際耗時（分鍾）
Planning	計划	30	35
Estimate	估計這個任務需要多少時間	30	20
Development	開發	180	210
Analysis	需求分析 (包括學習新技術)	30	40
Design Spec	生成設計文檔	20	10
Design Review	設計復審	20	10
Coding Standard	代碼規范 (為目前的開發制定合適的規范)	30	20
Design	具體設計	20	10
Coding	具體編碼	120	150
Code Review	代碼復審	30	20
Test	測試（自我測試，修改代碼，提交修改）	30	40
Reporting	報告	30	20
Test Repor	測試報告	30	20
Size Measurement	計算工作量	0	0
Postmortem & Process Improvement Plan	事后總結, 並提出過程改進計划	20	10
	合計		590

221701116(暮笑)

PSP2.1	Personal Software Process Stages	預估耗時（分鍾）	實際耗時（分鍾）
Planning	計划	30	30
Estimate	估計這個任務需要多少時間	30	20
Development	開發	180	210
Analysis	需求分析 (包括學習新技術)	30	40
Design Spec	生成設計文檔	30	10
Design Review	設計復審	40	10
Coding Standard	代碼規范 (為目前的開發制定合適的規范)	30	20
Design	具體設計	20	30
Coding	具體編碼	120	155
Code Review	代碼復審	25	45
Test	測試（自我測試，修改代碼，提交修改）	30	50
Reporting	報告	30	20
Test Repor	測試報告	30	20
Size Measurement	計算工作量	0	0
Postmortem & Process Improvement Plan	事后總結, 並提出過程改進計划	20	10
	合計		685

221701105(邵研)

PSP2.1	Personal Software Process Stages	預估耗時（分鍾）	實際耗時（分鍾）
Planning	計划	2	1
Estimate	估計這個任務需要多少時間	2	1
Development	開發	510	602
Analysis	需求分析 (包括學習新技術)	20	60
Design Spec	生成設計文檔	30	30
Design Review	設計復審	10	10
Coding Standard	代碼規范 (為目前的開發制定合適的規范)	10	2
Design	具體設計	50	120
Coding	具體編碼	300	250
Code Review	代碼復審	60	100
Test	測試（自我測試，修改代碼，提交修改）	30	30
Reporting	報告	60	45
Test Repor	測試報告	30	30
Size Measurement	計算工作量	20	10
Postmortem & Process Improvement Plan	事后總結, 並提出過程改進計划	10	5
合計	542	633

221701104(潘晨宇)

PSP2.1	Personal Software Process Stages	預估耗時（分鍾）	實際耗時（分鍾）
Planning	計划	20	10
Estimate	估計這個任務需要多少時間	12	30
Development	開發	240	220
Analysis	需求分析 (包括學習新技術)	20	40
Design Spec	生成設計文檔	15	30
Design Review	設計復審	10	10
Coding Standard	代碼規范 (為目前的開發制定合適的規范)	10	8
Design	具體設計	60	120
Coding	具體編碼	300	240
Code Review	代碼復審	60	90
Test	測試（自我測試，修改代碼，提交修改）	30	30
Reporting	報告	60	45
Test Repor	測試報告	30	30
Size Measurement	計算工作量	20	10
Postmortem & Process Improvement Plan	事后總結, 並提出過程改進計划	30	60
合計	700	730

第二部分

團隊選題展示過程中，老師和同學提出了一些問題。以下問題我們想現在予以解答

• 怎樣防止數據庫攻擊？

  就目前而言，我們了解到的數據庫攻擊有三個：口令破解、針對數據庫漏洞以及SQL注入攻擊。

  • 針對口令破解。是指數據庫用戶的用戶名和和口令被黑客破解。一般的默認口令容易被破解，比如用戶名“root"或者Scott的默認口令為tiger。但是除此以外對數據庫的破解即使不在默認情況下依然容易，現在網上就存在許多破解的軟件。為了應對這一問題，就要避免使用默認口令，建立強健的口令管理程序並對口令經常改變。

  • 針對數據庫漏洞攻擊，數據庫廠商總是小心翼翼地避免披露其補丁程序所修正的漏洞細節，但單位仍以極大的人力和時間來苦苦掙扎，它會花費人力物力來測試和應用一個數據庫補丁。例如，給程序打補丁要求對受補丁影響的所有應用程序都進行測試，這是項艱巨的任務。 而且一些黑客站點將一些已知的數據庫漏洞的利用腳本發布了出來。為了應對這一問題，就要及時更新數據庫，更新補丁，補上漏洞。

  • 針對SQL注入攻擊：

    在字段可用於用戶輸入，通過SQL語句可以實現數據庫的直接查詢時，就會發生SQL攻擊。黑客通過對SQL語句中某些未進行規范化檢查的語句進行攻擊，SQL注入攻擊被俗稱為黑客的填空游戲。所以在寫SQL語句的時候要注意規范化檢查，在寫web程序的時候也要對數據進行規范檢查，防止被鑽漏洞。

• 時間軸打算怎么處理？

  還是按照最初的設想，可以新建成若干的時間軸，其中的時間長短可以由用戶進行選擇，比如一天或者一周或者一個月、一年，在新建完時間軸后，允許使用略縮圖使得盡可能多的部分展現在屏幕上（不會影響觀感），允許用戶進行拖動和添加。

在上次團隊選題之后，你們組有什么新的思考和想法？

1. 在社交平台的開發上，我們的大平台是選擇類似微博的形式，這也意味着平台的大開發也許並不需要我們自己進行，而可以利用現有的開發信息，可以在github上尋找開源的平台開發源碼，直接套用即可獲得一個現有的信息交流平台。

2. 關於TAG搜索是否需要多元化？

   目標的搜索功能是允許用戶進行文字、語音、圖片的搜索。我們仔細考慮了以下是否需要如此多的功能，會不會給我們的開發造成困難。我們經過調查發現百度或者google有直接的API接口以獲得文字查詢或者圖片查詢的方法，但是我們認為語音查詢可能有些過於繁瑣，而且我們的開發更偏向webapp，真正願意使用語音搜索的用戶應該不會很多，所以我們放棄了語音搜索功能，保留了文字和圖片的搜索。

3. 這次的開發要往移動端開發還是web端開發？

   說實話此類項目確實移動端開發更加吃香。但是我們的組內並沒有之前開發過android和iOS的同學，所以我們的如果開發移動端程序面臨的阻力是很大的，但是我們可以退而求其次，我們可以開發webapp，雖然使用的熱度可能會下降，但是可以兼容PC和移動端，而且根據我們積累的開發經驗我們可以更好地進行開發。