201971010160-謝家俊 實驗三 結對專案—《{0-1}KP 例項資料集演算法實驗平臺》專案報告
阿新 • • 發佈:2022-04-04
專案 | 內容 |
---|---|
課程班級部落格連結 | 2019級卓越工程師班 |
這個作業要求連結 | 實驗三 軟體工程結對專案 |
我的課程學習目標 | 1.掌握Github協作開發程式的操作方法; 2.體驗軟體專案開發中的兩人合作,練習結對程式設計; 3.複習並熟悉PSP流程。 |
這個作業在哪些方面幫助我實現學習目標 | 兩人合作練習結對程式設計、掌握GitHub協作開發程式的操作方法以及運用學習工具 |
結對方學號-姓名 | 201971010101-阿麗米拉 |
結對方本次部落格作業連結 | 結對方部落格連結 |
專案Github的倉庫連結地址 | Github倉庫 |
任務一:閱讀《現代軟體工程—構建之法》第3-4章內容,理解並掌握程式碼風格規範、程式碼設計規範、程式碼複審、結對程式設計概念。
第3章(軟體工程師的成長)的理論和知識點主要有:評價軟體工程師水平的主要方法、技能的反面、TSP對個人的要求、軟體工程師的思維誤區等;第4章(兩人合作)的理論和知識點主要有:程式碼規範、極限程式設計、兩人合作的不同階段、影響他人的技巧。
- 程式碼風格規範:
主要是文字上的規定,看似表面文章,實際上非常重要。程式碼風格的原則是:簡明,易讀,無二義性。- 縮排:使用4個空格。
- 行寬:可為100字元。
- 括號:在複雜的條件表示式中,用括號清楚地表示邏輯優先順序。
- 分行:不要把不同的變數定義在一行上。
- 命名:在變數面前加上有意義的字首,就可以讓程式設計師一眼看出變數的型別及相應的語義。這就是“匈牙利命名法”的用處。
- 註釋:複雜的註釋應該放在函式頭,註釋應只用ASCII字元。
- 下劃線問題:下劃線用來分隔變數名字中的作用域標註和變數的語義。
- 斷行與空白的{ }行: 每個“{”和“}”都獨佔一行。
- 大小寫問題:由多個單片語成的變數名,如果全部都是小寫,很不易讀,一個簡單的解決方案就是用大小寫區分它們。
- 程式碼設計規範:
牽涉到程式設計、模組之間的關係、設計模式等方方面面,這裡有不少與具體程式設計語言息息相關的內容(如C/C++/Java/C#),但是也有通用的原則,這裡主要討論通用的原則。- 函式:現代程式設計語言中的絕大部分功能,都在程式的函式(Function, Method)中實現,關於函式最重要的原則是:只做一件事,但是要做好。
- goto:函式最好有單一的出口,為了達到這一目的,可以使用goto。
- 錯誤處理:
1.引數處理:在DeBug版本中,所有的引數都要驗證其正確性。在正式版本中,從外部(使用者或別的模組)傳遞過來的引數要驗證其正確性。
2.斷言: 如何驗證正確性?那就要用Assert(斷言)。斷言和錯誤處理是什麼關係?當你覺得某事肯定如何,你可以用斷言。Assert (p != NULL);然後可以直接使用變數p;如果你認為某事可能會發生,這時就要用錯誤處理。
- 程式碼複審:
看程式碼是否在“程式碼規範”的框架內正確地解決了問題
名稱 | 形式 | 目的 |
---|---|---|
自我複審 | 自己vs.自己 | 用同伴複審的標準來要求自己。不一定最有效,因為開發者對自己總是過於自信。如果能持之以恆,則對個人有很大好處 |
同伴複審 | 複審者 vs. 開發者 | 簡便易行 |
團隊複審 | 團隊 vs. 開發者 | 有比較嚴格的規定和流程,用於關鍵的程式碼,以及複審後不再更新的程式碼。 覆蓋率高——有很多雙眼睛盯著程式。但是有可能效率不高(全體人員都要到會) |
- 程式碼複審的目的:
- 找出程式碼的錯誤:編碼錯誤,比如一些能碰巧騙過編譯器的錯誤。
- 發現邏輯錯誤:程式可以編譯通過,但是程式碼的邏輯是錯的。
- 發現演算法錯誤:使用的演算法不夠優化。
- 發現潛在的錯誤和迴歸性錯誤:當前的修改導致以前修復的缺陷又重新出現。
- 發現可能改進的地方。
- 教育(互相教育)開發人員,傳授經驗,讓更多的成員熟悉專案各部分的程式碼,同時熟悉和應用領域相關的實際知識。
- 結對程式設計:
是一種敏捷軟體開發的方法,兩個程式設計師在一個計算機上共同工作,是極限程式設計的組成部分。一個人輸入程式碼,稱作駕駛員;另一個人負責審查工作,稱作觀察員(或導航員)。兩人常互換角色。在結對程式設計中,觀察員同時考慮工作的戰略性方向,提出改進的意見,或將來可能出現的問題以便處理。
任務二:兩兩自由結對,對結對方《實驗二 軟體工程個人專案》的專案成果進行評價,具體要求如下:
(1)對專案博文作業進行閱讀並進行評論,評論要點包括:博文結構、博文內容、博文結構與PSP中“任務內容”列的關係、PSP中“計劃共完成需要的時間”與“實際完成需要的時間”兩列資料的差異化分析與原因探究,將以上評論內容釋出到部落格評論區。
(2)克隆結對方專案原始碼到本地機器,閱讀並測試執行程式碼,參照《現代軟體工程—構建之法》4.4.3節核查表複審同伴專案程式碼並記錄。
專案 | 內容 |
---|---|
結對方部落格連結 | 201971010101-阿麗米拉 |
結對方Github專案倉庫連結 | Github |
-
部落格評論
從GitHub下載了結對對方的程式碼: -
程式碼核查表
專案部分 | 完成情況 |
---|---|
概要部分 | |
程式碼能符合需求和規格說明麼? | 程式碼完成了部分需求,程式碼編寫基本規範 |
程式碼設計是否有周全的考慮? | 否 |
程式碼的可讀性? | 簡單易讀 |
程式碼是否容易維護? | 易維護 |
程式碼的每一行是否都執行並檢查過? | 是 |
設計規範部分 | |
設計是否遵從已知的設計模式或專案中常用的模式? | 是 |
有沒有硬編碼或字串/數字等存在? | 沒有 |
程式碼有沒有依賴於某一平臺,是否會影響將來的移植? | 否 |
開發者新寫的程式碼是否用已有的Library/SDK/Framework中的功能實現?在本專案中是否存在類似的功能可以通過呼叫而不用全部重新實現? | 否 |
有沒有無用的程式碼可以清除? | 否 |
程式碼規範部分 | |
修改的部分符合程式碼標準和風格麼? | 符合 |
具體程式碼部分 | |
有沒有對錯誤進行處理?對於呼叫的外部函式,是否檢查了返回值或處理了異常? | 已處理 |
引數傳遞有無錯誤,字串的長度是位元組的長度還是字元的長度,是從0開始計數還是從1開始計數 | 無錯誤 |
邊界條件是如何處理的?switch語句和default分支是如何處理的?迴圈有沒有可能出現死迴圈? | 沒有出現死迴圈 |
有沒有使用斷言來保證我們認為不變的條件真的得到滿足? | 否 |
資料結構中有沒有用不到的元素? | 否 |
效能 | |
程式碼的效能如何?最壞的情況是怎麼樣的? | 效能一般 |
程式碼中,特別是迴圈中是否有明顯可優化的部分? | 有 |
對於系統和網路的呼叫是否會超時?如何處理? | 否 |
可讀性 | |
程式碼可讀性如何?有沒有足夠的註釋? | 程式碼有較好的可讀性,重要程式碼部分缺少註釋 |
可測試性 | |
程式碼是否需要更新或建立新的單元測試? | 否 |
任務三:採用兩人結對程式設計方式,設計開發一款{0-1}KP 例項資料集演算法實驗平臺,使之具有以下功能
1、平臺基礎功能:實驗二 任務3
- 可正確讀入實驗資料檔案的有效{0-1}KP資料;
- 能夠繪製任意一組{0-1}KP資料以價值重量為橫軸、價值為縱軸的資料散點圖;
- 能夠對一組{0-1}KP資料按重量比進行非遞增排序;
- 使用者能夠自主選擇貪心演算法、動態規劃演算法、回溯演算法求解指定{0-1} KP資料的最優解和求解時間(以秒為單位);
- 任意一組{0-1} KP資料的最優解、求解時間和解向量可儲存為txt檔案或匯出EXCEL檔案。
2、{0-1}KP 例項資料集需儲存在資料庫;
3、平臺可動態嵌入任何一個有效的{0-1}KP 例項求解演算法,並儲存演算法實驗日誌資料;
4、人機互動介面要求為GUI介面(WEB頁面、APP頁面都可);
5、查閱資料,設計遺傳演算法求解{0-1}KP,並利用此演算法測試要求(3); - 需求分析陳述:
- D{0-1}KP問題可以採用動態規劃演算法,回溯演算法以及遺傳演算法等多種演算法來解決,每一種演算法解決D{0-1}KP問題所消耗的時間和空間都有所不同,為了方便使用者快速的選擇某種演算法來解決D{0-1}KP問題並且比較每一種演算法執行時所消耗的時間和空間,所以我們試圖開發一個D{0-1}KP例項資料集演算法實驗平臺,以便使用者能夠快速的選擇某種演算法來解決D{0-1}KP問題並且比較出哪種演算法更高效。
- 軟體設計說明:
- 在實驗二-個人專案的基礎上進行開發;
- 人機互動介面通過python來編寫GUI介面;
- 將D{0-1}KP例項資料集儲存在資料庫,在GUI介面可進行資料的查詢;
- 輸入需要繪製散點圖或者需要排序的資料集以及資料項後進行散點圖的繪製或者資料的排序;
- 平臺動態嵌入有效的{0-1}KP例項求解演算法。
- 程式執行:
資料庫:
GUI介面:
散點圖:(beibao4)
排序:
核心程式碼展示:
散點圖的繪製:
def paint(list11=[],list22=[]):
import numpy as np
import matplotlib.pyplot as plt
plt.scatter(list11,list22)
plt.show()
資料排序:
def sort(list11=[],list22=[]):
win1 = tkinter.Toplevel()
win1.title('資料排序')
win1.geometry('500x300')
sw = win1.winfo_screenwidth()
sh = win1.winfo_screenheight()
win1.geometry('+%d+%d' % ((sw - 500) / 2, (sh - 300) / 2))
list4=[]
for i in range(2,len(list11)+1):
if i%3==0:
list4.append(round(int(list11[i-1])/int(list22[i-1]),3))
list4.sort(reverse=True)
tkinter.messagebox.showinfo("按照價效比的非遞增排序",list4)
win1.destroy()
介面的佈局:
win = tkinter.Tk()
win.title('D{0-1}揹包問題')
win.geometry('500x300')
win.configure(bg='Linen')
sw = win.winfo_screenwidth()
sh = win.winfo_screenheight()
win.geometry('+%d+%d' % ((sw - 500) / 2, (sh - 300) / 2))
l = tkinter.Label(win, text='{0-1}KP例項資料集演算法實驗平臺', font=('華文行楷', 24), fg='black')
l.place(relx=0.5, rely=0.1, anchor='center')
Lname = tkinter.Label(win, text='資料集檔名', font=('華文行楷', 19), fg='black')
Lname.place(relx=0.45, rely=0.3, anchor='center')
nu = tkinter.StringVar()
name = tkinter.Entry(win, textvariable=nu)
name.place(relx=0.51, rely=0.29, width=95)
choose = [('1.進行資料的查詢', 1), ('2.繪製資料散點圖', 2), ('3.對資料進行排序', 3), ('4.選擇演算法來求解', 4)]
v = tkinter.IntVar()
v.set(1)
x, y = 0.5, 0.5,
for a, b in choose:
cc = tkinter.Radiobutton(win, text=a, variable=v, value=b, font=('華文行楷', 20), fg='black')
cc.place(relx=x, rely=y, anchor='center')
y += 0.1
b = tkinter.Button(win, text='確定', width=10, height=3, bg='gray', command=secondMain)
b.place(relx=0, rely=1, anchor='sw')
b2 = tkinter.Button(win, text='退出', width=10, height=3, bg='gray', command=win.quit)
b2.place(relx=1, rely=1, anchor='se')
結對過程:
本次作業PSP
PSP2.1 | 任務內容 | 計劃共完成需要的時間(min) | 實際完成需要的時間(min) |
---|---|---|---|
Planning | 計劃 | 30 | 25 |
Estimate | 估計這個任務需要多少時間,並規劃大致工作步驟 | 30 | 25 |
Development | 開發 | 1120 | 983 |
Analysis | 需求分析 (包括學習新技術) | 310 | 260 |
Design Spec | 生成設計文件 | 90 | 60 |
Design Review | 設計複審 (和同事稽核設計文件) | 30 | 25 |
Coding Standard | 程式碼規範 (為目前的開發制定合適的規範) | 10 | 8 |
Design | 具體設計 | 60 | 40 |
Coding | 具體編碼 | 500 | 520 |
Code Review | 程式碼複審 | 60 | 40 |
Test | 測試(自我測試,修改程式碼,提交修改) | 60 | 30 |
Reporting | 報告 | 100 | 70 |
Test Report | 測試報告 | 60 | 30 |
Size Measurement | 計算工作量 | 10 | 10 |
Postmortem & Process Improvement Plan | 事後總結 ,並提出過程改進計劃 | 30 | 30 |
將專案上傳到GitHub上:
總結:
- 通過這次的結對和作完成專案,深切體會到結對的諸多好處,兩個人對於問題的分析和理解會更加深入,不會像一個人考慮時那麼片面,結對程式設計能提供更好的設計質量和程式碼質量,兩人合作能有更強的解決問題的能力。兩個人在一起會相互學習,傳遞經驗,取長補短;配合工作能夠提高工作效率,結對工作能帶來更多的信心。當然在這個過程中當中也遇到了一些問題,有時候兩個的時間上會有衝突,這就需要相互協調,也有時候兩個人的想法不一致等問題,但是我覺得結對程式設計利遠大於弊。