天天看點

軟體工程第一次結對作業

1.題目要求

(1). 首先在同學中找一個同伴,範圍不限,可以在1~5班中随意組合,建議盡量不要找同組的成員,女同學盡量找男同學結對,但是不做強制要求;

(2). 從以往個人完成的項目中選擇一個作品,例如:以往的資料結構課程設計或者其它具有比較完整功能的小系統,代碼至少要大于100行;

(3). 将代碼上傳至個人GitHub或Coding.net系統中,并将代碼位址交給對方;

(4). 對同伴的作品進行代碼複審,并參照C/C++代碼審查表和 Java代碼審查表 這兩篇博文的内容自行設計代碼審查表并填寫内容;

(5). 将對夥伴審查的結果以表格的形式寫到自己的部落格作業裡,部落格中應該附有夥伴作業的GitHub或Coding.net的代碼位址;

(6). 對同伴的代碼寫一篇500字以上的評論,介紹同伴的優缺點。

2.代碼位址

代碼托管所位址:

軟體工程第一次結隊作業

3.審查表

功能子產品名稱 用kruskal算法求最小生成樹各邊的權值之和
審查人 張浩 審查日期 2019年4月24日
代碼名稱 用kruskal算法求最小生成樹各邊的權值之和 代碼作者 王鵬
檔案結構
重要性 審查項 結論
重要 頭檔案和定義檔案的名稱是否合理
頭檔案和定義檔案的目錄結構是否合理
重要 版權和版本聲明是否完整?
頭檔案是否使用了ifndef/define/endif預處理塊?
重要 頭檔案中是否隻存放“聲明”而不存放“定義” 定義了全局變量
程式的版式
重要性 審查項 結論
空行是否得體?
代碼行内的空格是否得體?
長行拆分是否得體?
“{”和“}”是否各占一行并且對齊于同一列? “{”跟随在上一語句之後
重要 一行代碼是否隻做一件事?如定義一個變量,隻寫一條語句 存在一行多個變量的問題
重要 if ,for,while,do等語句自占一行,不論執行語句多少都要加“{}” 多條語句才加“{}”
重要 在定義變量(或參數)時,是否将修飾符*和&緊靠變量名?注釋是否清晰并且必要 否否否 基本沒注釋,看得老累了
重要 注釋是否有錯誤或者可能導緻誤解? 基本沒注釋
重要 類結構的public,protected,private順序是否在所有的程式中保持一緻?
命名規則
重要性 審查項 結論
重要 命名規則是否與所采用的作業系統或開發工具的風格保持一緻?
辨別符是否直覺且可以拼讀?
辨別符的長度應當符合“min-length && max-information”原則?
重要 程式中是否出現相同的局部變量和全部變量? i,j用了好幾次
類名、函數名、變量和參數、常量的書寫格式是否遵循一定的規則? 大小寫區分
靜态變量、全局變量、類的成員變量是否加字首?
表達式與基本語句
重要性 審查項 結論
重要 如果代碼行中的運算符比較多,是否已經用括号清楚地确定表達式的操作順序?
是否編寫太複雜或者多用途的複合表達式?
重要 是否将複合表達式與“真正的數學表達式”混淆?
重要 是否用隐含錯誤方式寫if語句?例如
(1)将布爾變量直接與TRUE、FALSE或者1、0進行比較。
(2)将浮點變量用“==”或“!=”與任何數字比較。
(3)将指針變量用“==”或“!=”與NULL比較。
如果循環體記憶體在邏輯判斷,并且循環次數很大,是否已經将邏輯判斷移到循環體的外面?
重要 Case語句的結尾是否忘了加break?
重要 是否忘記了switch的fault分支?
重要 使用goto 語句時是否留下隐患? 例如跳過了某些對象的構造、變量的初始化、重要的計算等。 沒有用goto
常量
重要性 審查項 結論
是否使用含義直覺的常量來表示那些将在程式中多次出現的數字或字元串? 例如min,max
在C++ 程式中,是否用const常量取代宏常量?
重要 如果某一常量與其它常量密切相關,是否在定義中包含了這種關系?
是否誤解了類中的const資料成員?因為const資料成員隻在某個對象生存期内是常量,而對于整個類而言卻是可變的。
函數設計
重要性 審查項 結論
參數的書寫是否完整?不要貪圖省事隻寫參數的類型而省略參數名字。
參數命名、順序是否合理? 參數命名有點随便
參數的個數是否太多?
是否使用類型和數目不确定的參數?
是否省略了函數傳回值的類型?
函數名字與傳回值類型在語義上是否沖突?
重要 是否将正常值和錯誤标志混在一起傳回?正常值應當用輸出參數獲得,而錯誤标志用return語句傳回。
重要 在函數體的“入口處”,是否用assert對參數的有效性進行檢查?
重要 使用濫用了assert? 例如混淆非法情況與錯誤情況,後者是必然存在的并且是一定要作出處理的。
重要 return語句是否傳回指向“棧記憶體”的“指針”或者“引用”?
是否使用const提高函數的健壯性?const可以強制保護函數的參數、傳回值,甚至函數的定義體。“Use const whenever you need”
記憶體管理
重要性 審查項 結論
重要 用malloc或new申請記憶體之後,是否立即檢查指針值是否為NULL?(防止使用指針值為NULL的記憶體)
重要 是否忘記為數組和動态記憶體賦初值?(防止将未被初始化的記憶體作為右值使用) 進行了指派
重要 數組或指針的下标是否越界? 數組開得比較大
重要 動态記憶體的申請與釋放是否配對?(防止記憶體洩漏)
重要 是否有效地處理了“記憶體耗盡”問題?
重要 是否修改“指向常量的指針”的内容?
重要 是否出現野指針?例如(1)指針變量沒有被初始化;(2)用free或delete釋放了記憶體之後,忘記将指針設定為NULL。
重要 是否将malloc/free 和 new/delete 混淆使用?
重要 malloc語句是否正确無誤?例如位元組數是否正确?類型轉換是否正 确?
重要 在建立與釋放動态對象數組時,new/delete的語句是否正确無誤?
C++ 函數的進階特性
重要性 審查項 結論
重載函數是否有二義性?
重要 是否混淆了成員函數的重載、覆寫與隐藏?
運算符的重載是否符合制定的程式設計規範?
是否濫用内聯函數?例如函數體内的代碼比較長,函數體内出現循環。
重要 是否用内聯函數取代了宏代碼?
類的構造函數、析構函數和指派函數
重要性 審查項 結論
重要 是否違背程式設計規範而讓C++ 編譯器自動為類産生四個預設的函數:
(1)預設的無參數構造函數;
(2)預設的拷貝構造函數;
(3)預設的析構函數;
(4)預設的指派函數;
重要 構造函數中是否遺漏了某些初始化工作?
重要 是否正确地使用構造函數的初始化表?
重要 析構函數中是否遺漏了某些清除工作?
是否錯寫、錯用了拷貝構造函數和指派函數?
重要 指派函數一般分四個步驟:
(1)檢查自指派;
(2)釋放原有記憶體資源;
(3)配置設定新的記憶體資源,并複制内容;
(4)傳回this*。是否遺漏了重要步驟?
注意事項:
(1)派生類不可能繼承基類的構造函數、析構函數、指派函數。
(2)派生類的構造函數應在其初始化表裡調用基類的構造函數。
(3)基類與派生類的析構函數應該為虛(即加virtual關鍵字)。
(4)在編寫派生類的指派函數時,注意不要忘記對基類的資料成員重新指派
類的進階特性
重要性 審查項 結論
重要 是否違背了繼承群組合的規則?
(1)若在邏輯上B是A的“一種”,并且A的所有功能和屬性對B而言都有意義,則允許B繼承A的功能和屬性。
(2)若在邏輯上A是B的“一部分”(a part of),則不允許B從A派生,而是要用A和其它東西組合出B。
其它常見問題
重要性 審查項 結論
重要 資料類型問題:
(1)變量的資料類型有錯誤嗎啊?
(2)存在不同資料類型的指派嗎?
(3)存在不同資料類型的比較嗎?
重要 變量值問題:
(1)變量的初始化或預設值有錯誤嗎?
(2)變量發生上溢或下溢嗎?
(3)變量的精度夠嗎?
重要 邏輯判斷問題:
(1)由于精度原因導緻比較無效嗎?
(2)表達式中的優先級有誤嗎?
(3)邏輯判斷的結果颠倒嗎?
重要 循環問題:
(1)循環條件不正确嗎?
(2)無法正常終止(死循環)嗎?
(3)錯誤地修改循環變量嗎?
(4)存在誤差累積嗎?
重要 錯誤處理問題:
(1)忘記進行錯誤處理嗎?
(2)錯誤處理程式塊一直沒有機會呗運作嗎?
(3)錯誤處理程式塊本身就有毛病嗎?如報告的錯誤與實際錯誤不一緻,處理方式不正确等等。
(4)錯誤處理程式塊是“馬後炮”嗎?如在被它被調用之前軟體已經出錯。
重要 檔案I/O問題:
(1)對不存在的或者錯誤的檔案進行操作嗎?
(2)檔案以不正确的方式打開嗎?
(3)檔案結束判斷不正确嗎?
(4)沒有正确地關閉檔案嗎?

4.代碼分析與個人感受

   本次作業是要求兩兩一對,審查彼此的代碼,剛開始我對這種方法表示不了解,一份代碼,最了解和最懂它的肯定是它的編寫人員,也就是程式員本身,讓去看其他人的代碼,既費時又費力,可當我仔細看完别人的代碼後才深深的知道了兩人代碼複審的好處,通過觀看别人的代碼,你可以發現他許多的不足之處,而這些不好的地方恰恰可能我們自己也有,同時也會發現别人和我們不同的程式設計思路,有時候看着看着就發現,原來還可以這麼做啊,以前都沒想到。通過看别人的代碼,讓我收獲良多。

   我這次作業複審的是王鵬同學的代碼,代碼是要求用kruskal算法求最小生成樹各邊的權值之和,kruskal算法即克魯斯卡爾算法,指求權重連通圖的最小生成樹的算法。kruskal算法總共選擇n- 1條邊,所使用的貪婪準則是:從剩下的邊中選擇一條不會産生環路的具有最小耗費的邊加入已選擇的邊的集合中。注意到所選取的邊若産生環路則不可能形成一棵生成樹。kruskal算法分e步,其中e是網絡中邊的數目。按耗費遞增的順序來考慮這e條邊,每次考慮一條邊。當考慮某條邊時,若将其加入到已選邊的集合中會出現環路,則将其抛棄,否則,将它選入。代碼有許多做得很好的地方,值得去學習,但是也有一些做得不好的地方。

優點

(1). 代碼的有些變量定義規範,采用了較為容易了解的變量來命名。

int lowcost[100];
    int teend[100];
    int mincost;
    int length = 0;
           

(2). 代碼書寫較為規範,空格和換行使用恰當。

(3). 在編寫代碼之前特意将題目要求以注釋的形式放在了代碼内,便于閱讀

缺點

(1). “{}”使用不恰當,“{”總是放在代碼的末尾,沒有重寫一行,不利于閱讀。

for (i = 0; i < numV; i++)
        for (j = 0; j < numV; j++) {
            Graph[i][j] = INT_MAX;
        }
    for (i = 0; i < numE; i++) {

        scanf("%d%d%d", &a, &b, &c);
        Graph[a - 1][b - 1] = c;
        Graph[b - 1][a - 1] = c;

    }
           

(2). 代碼注釋很少,不利于閱讀,在剛開始閱讀代碼時無法快速了解代碼含義。

(3). 部分變量命名不規範,比如有幾個變量直接以abc命名,看了半天才知道abc具體代表什麼。

總結

以上他的代碼中出現的一些問題我自己也有,比如命名不規範,經常性的命名變量abcde一大串,最後自己都不知道變量具體代表啥了,除此之外通過這次代碼複審教會我最重要的就是一定要給代碼加上注釋,注釋,尤其是一些比較難懂的代碼,如果不加注釋,當時可能是懂了,過幾天以後回頭再看發現又不懂了,是以加注釋,既能友善自己查閱,也能友善他人很快的了解你的代碼。

轉載于:https://www.cnblogs.com/zhangwwy/p/10761702.html

繼續閱讀