201971010208-古麗妮尕爾 實驗三 結對專案—《{0-1}KP 例項資料集演算法實驗平臺》專案報告
阿新 • • 發佈:2022-04-04
專案 | 內容 |
---|---|
課程班級部落格連結 | 2019級卓越工程師班 |
這個作業要求連結 | 實驗三 軟體工程結對專案 |
我的課程學習目標 |
|
這個作業在哪些方面幫助我實現學習目標 |
|
專案Github的倉庫連結地址 | 倉庫連結 |
結對方學號姓名 | 201971010145_姚恪 |
結對方本次部落格作業連結 | 結對方作業連結 |
任務1:閱讀《現代軟體工程—構建之法》第3-4章內容,理解並掌握程式碼風格規範、程式碼設計規範、程式碼複審、結對程式設計概念;
-
程式碼風格規範
- 原則:簡單、易讀、無二義性。
- 縮排:可以使用Tab鍵以及2、4、8等空格。個人認為依據不同是程式語言,可以使用不同的縮排方式。
- 行寬:對行寬進行同一設定。
- 括號:用括號清楚的表明邏輯優先順序。
- 分行:不要把多條語句放在一行上。
- 命名:命名能夠表明變數的型別及相應的語義,簡潔易懂。
- 下換線:合理使用來分隔變數名字中的作用域標註和變數的語義。
- 大小寫:多個單次組成的變數名,用大小寫區分,例如著名的駝峰式命名法。
- 註釋:能夠很好的解釋程式是做什麼的,以及為什麼這樣做
-
程式碼設計規範
- 概念:程式碼設計規範不光是程式書寫的格式問題,而且涉及到程式設計、模組之間的關係、設計模式等方方面面,又有不少內容與具體程式設計語言息息相關(如C,C++,JAVA,C#),但是也有通用的原則。
- 函式:原則:只做一件事,並且要做好。
- goto:函式最好有單一出口,為了達到這一目的,可以使用goto。
- 錯誤處理(引數處理):在Debug版本中,所有引數都要驗證其正確性。
- 錯誤處理(斷言):檢驗正確性時,可以使用斷言。
- 類:
1.使用類來封裝面向物件的概念和多型。
2.避免傳遞型別實體的值,應該用指標傳遞。換句話說,對於簡單的資料型別,沒有必要要用類來實現。
3.對於有顯示的構造和析構的類,不要建立全域性的實體,因為不知道它們在何時建立和消除。
4.僅在有必要時,才是用“類”。 - class vs. struct:如果只是資料的封裝,用struct即可。
- 公共/保護/私有成員:按照這樣的次序來說明類中的成員。
- 資料成員:
1.資料型別的成員用m_name說明。
2.不要使用公共的資料成員,要用inline訪問函式,這樣才可兼顧封裝和效率。 - 虛擬函式:
1.實現多型。
2.僅在很有必要時,使用虛擬函式。
3.若一型別實現多型,在基類中的解構函式應該是虛擬函式。 - 建構函式:
1.不做複雜操作。
2.不應返回錯誤。 - new 和 delete:
1.儘量實現自己的new/delete。
2.檢查new的返回值。
3.釋放指標時不用檢查NULL。 - 運算子:
1.無需自定義操作符。
2.不要做標準語義之外的動作。
3.運算子的實現必須非常有效率。
4.當打不定主意時,用成員函式。 - 異常:
1.不要將異常作為處理程式主要流程。
2.瞭解異常及處理異常的花銷。
3.使用時,注意在什麼地方清理資料。
4.異常不能跨過DLL或程序的邊界來傳遞資訊。 - 型別繼承:
1.僅在必要時使用。
2.用const標註只讀的引數。
3.用const標註不改變資料的函式。
-
程式碼複審
- 定義:看程式碼是否在程式碼規範的框架正確地解決了問題。
- 形式:自我複審、同伴複審、團隊複審。
-
結對程式設計概念
- 結對程式設計能提供更好的設計質量和程式碼質量,兩人合作解決問題的能力更強。
- 結對工作,信心大增,高質量的產出帶來高滿足感。
- 結對能更有效的交流,相互學習傳遞經驗,分享知識,應對人員流動。
任務2:兩兩自由結對,對結對方《實驗二 軟體工程個人專案》的專案成果進行評價。
結對物件 | 專案 | 倉庫 |
---|---|---|
姚恪—201971010145 | 實驗二 | 姚恪倉庫 |
- 成果評價
評價專案 | 評價內容 |
---|---|
博文結構 | 頁面簡介整齊,要素齊全且一目瞭然。 |
博文內容 | 最大程度達到了作業要求,極少部分地方出現了文字不對齊、序號重複等形式錯誤,內容飽滿且完整 |
博文結構與PSP中“任務內容”列的關係 | 博文結構與“內容任務”列幾乎一一對應,思路清晰 |
PSP資料的差異化分析與原因探究 | 具體完成時間與計劃完成時間相差無幾,因為本身具有紮實的程式碼功底以及規劃能力,即使個別專案所用時間超出計劃部分也沒有因此拖整體進度。 |
-
克隆結對方專案原始碼到本地機器,閱讀並測試執行程式碼,參照《現代軟體工程—構建之法》4.4.3節核查表複審同伴專案程式碼並記錄。
- 克隆對方專案
- 測試程式碼
- 克隆對方專案
-
程式碼審查
概要部分 | 執行情況 |
---|---|
程式碼符合需求和規格說明麼? | 符合 |
程式碼設計是否考慮周全? | 是 |
程式碼可讀性如何? | 符合程式碼規範,註釋簡單易懂 |
程式碼容易維護麼? | 容易 |
程式碼的每一行都執行並檢查過了嗎? | 檢查過了 |
設計規範部分 | |
設計是否遵從已知的設計模式或專案中常用的模式? | 遵從 |
有沒有硬編碼或字串/數字等存在 | 不存在 |
程式碼有沒有依賴於某一平臺,是否會影響將來的移植(如Win32到Win64)? | 不影響 |
在本專案中是否存在類似的功能可以呼叫而不用全部重新實現? | |
有沒有無用的程式碼可以清除? | 無 |
程式碼規範部分 | |
修改的部分符合程式碼標準和風格嗎? | 符合 |
具體程式碼部分 | |
有沒有對錯誤進行處理?對於呼叫的外部函式,是否檢查了返回值或處理了異常? | 沒有對錯誤進行預處理 |
引數傳遞有無錯誤,字串的長度是位元組的長度還是字元(可能是單/雙位元組)的長度是以0開始計數還是以1開始計數? | 無 |
邊界條件是如何處理的? switch語句的default分支是如何處理的?迴圈有沒有可能出現死迴圈? | 沒有使用switch語句所以迴圈不會出現死迴圈。 |
有沒有使用斷言( Assert)來保證我們認為不變的條件真的得到滿足? | 沒有使用斷言 |
資料結構中有沒有用不到的元素? | 看不出來 |
效能 | |
程式碼的效能(Performance)如何?最壞的情況是怎樣的? | 執行效率高,沒有遇到最壞的情況 |
程式碼中,特別是迴圈中是否有明顯可優化的部分? | 無 |
對於系統和網路的呼叫是否會超時?如何處理? | 沒有進行網路呼叫 |
可讀性 | |
程式碼可讀性如何?有沒有足夠的註釋? | 註釋簡潔明瞭,符合規範 |
可測試性 | |
程式碼是否需要更新或建立新的單元測試? | 否 |
- 結對方專案倉庫中的Fork、Clone、Push、Pull request、Merge pull request日誌資料
任務3:採用兩人結對程式設計方式,設計開發一款{0-1}KP 例項資料集演算法實驗平臺
- 需求分析
- 平臺基礎功能:實驗二 任務3;
- {0-1}KP 例項資料集需儲存在資料庫;
- 平臺可動態嵌入任何一個有效的{0-1}KP 例項求解演算法,並儲存演算法實驗日誌資料;
- 人機互動介面要求為GUI介面(WEB頁面、APP頁面都可);
- 查閱資料,設計遺傳演算法求解{0-1}KP,並利用此演算法測試要求(3);
- 附加功能:除(1)-(5)外的任意有效平臺功能實現。
- 軟體設計說明
- 將實驗二的程式碼進行了擴充,套裝了一個django框架
- 但是僅僅能夠實現資料的前端展示,是一個假的前端,沒有完全實現前端功能
- 使用python中django庫中自帶的sqlite資料庫進行資料的傳輸
- 功能流程圖
- 核心程式碼