1. 程式人生 > 其它 >201971010208-古麗妮尕爾 實驗三 結對專案—《{0-1}KP 例項資料集演算法實驗平臺》專案報告

201971010208-古麗妮尕爾 實驗三 結對專案—《{0-1}KP 例項資料集演算法實驗平臺》專案報告

專案 內容
課程班級部落格連結 2019級卓越工程師班
這個作業要求連結 實驗三 軟體工程結對專案
我的課程學習目標
  • 體驗軟體專案開發中的兩人合作,練習結對程式設計(Pair programming)
  • 掌握Github釋出軟體專案的操作方法
這個作業在哪些方面幫助我實現學習目標
  • 實踐學習與他人合作,練習結對程式設計,認識程式碼規範的重要性
  • 掌握Github釋出軟體專案的操作方法
專案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資料庫進行資料的傳輸
    • 功能流程圖
  • 核心程式碼