軟件工程第一次結對做業

博客信息	瀋陽航空航天大學計算機學院2020軟件工程做業
做業要求	https://edu.cnblogs.com/campus/sau/Computer1701-1705/homework/10616
課程目標	熟悉一個「高質量」軟件的開發過程
做業目標	熟悉代碼規範及結對互審

 

1、夥伴代碼地址

代碼地址

2、代碼審查

功能模塊名稱	論文檢索系統
審查人	黃博	審查日期	2020/4/16
代碼名稱	main.cpp	代碼做者	李鑫宇
文件結構
重要性	審查項	結論
	頭文件和定義文件的名稱是否合理？	是
	頭文件和定義文件的目錄結構是否合理？	是
	版權和版本聲明是否完整？	無
重要	頭文件是否使用了 ifndef/define/endif 預處理塊?	否
	頭文件中是否只存放「聲明」而不存放「定義」	否
程序的版式
重要性	審查項	結論
	空行是否得體？	是
	代碼行內的空格是否得體？	是
	長行拆分是否得體？	是
	「{」 和 「}」 是否各佔一行而且對齊於同一列？	是
重要	一行代碼是否只作一件事？如只定義一個變量，只寫一條語句。	是
重要	If、for、while、do等語句自佔一行，不論執行語句多少都要加 「{}」。	是
重要	在定義變量（或參數）時，是否將修飾符 * 和 ＆ 緊靠變量名？註釋是否清晰而且必要？	是
重要	註釋是否有錯誤或者可能致使誤解？	否
重要	類結構的public, protected, private順序是否在全部的程序中保持一致？	無
命名規則
重要性	審查項	結論
重要	命名規則是否與所採用的操做系統或開發工具的風格保持一致？	是
	標識符是否直觀且能夠拼讀？	是
	標識符的長度應當符合「min-length && max-information」原則？	是
重要	程序中是否出現相同的局部變量和所有變量？	否
	類名、函數名、變量和參數、常量的書寫格式是否遵循必定的規則？	否
	靜態變量、全局變量、類的成員變量是否加前綴？	否
表達式與基本語句
重要性	審查項	結論
重要	若是代碼行中的運算符比較多，是否已經用括號清楚地肯定表達式的操做順序？	是
	是否編寫太複雜或者多用途的複合表達式？	否
重要	是否將複合表達式與「真正的數學表達式」混淆？	否
重要	是否用隱含錯誤的方式寫if語句? 例如
	（1）將布爾變量直接與TRUE、FALSE或者一、0進行比較。	是
	（2）將浮點變量用「==」或「！=」與任何數字比較。	是
	（3）將指針變量用「==」或「！=」與NULL比較。	是
	若是循環體內存在邏輯判斷，而且循環次數很大，是否已經將邏輯判斷移到循環體的外面？	是
重要	Case語句的結尾是否忘了加break？	否
重要	是否忘記寫switch的default分支？	否
重要	使用goto 語句時是否留下隱患? 例如跳過了某些對象的構造、變量的初始化、重要的計算等。	否
常量
重要性	審查項	結論
	是否使用含義直觀的常量來表示那些將在程序中屢次出現的數字或字符串？	是
	在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。	無
其它常見問題
重要性	審查項	結論
重要	數據類型問題：
	（１）變量的數據類型有錯誤嗎？	否
	（２）存在不一樣數據類型的賦值嗎？	否
	（３）存在不一樣數據類型的比較嗎？	否
重要	變量值問題：
	（１）變量的初始化或缺省值有錯誤嗎？	否
	（２）變量發生上溢或下溢嗎？	否
	（３）變量的精度夠嗎？	是
重要	邏輯判斷問題：
	（１）因爲精度緣由致使比較無效嗎？	否
	（２）表達式中的優先級有誤嗎？	否
	（３）邏輯判斷結果顛倒嗎？	否
重要	循環問題：
	（１）循環終止條件不正確嗎？	否
	（２）沒法正常終止（死循環）嗎？	否
	（３）錯誤地修改循環變量嗎？	否
	（４）存在偏差累積嗎？	否
重要	錯誤處理問題：
	（１）忘記進行錯誤處理嗎？	否
	（２）錯誤處理程序塊一直沒有機會被運行？	否
	（３）錯誤處理程序塊自己就有毛病嗎？如報告的錯誤與實際錯誤不一致，處理方式不正確等等。	否
	（４）錯誤處理程序塊是「馬後炮」嗎？如在被它被調用以前軟件已經出錯。	否
重要	文件I/O問題：
	（１）對不存在的或者錯誤的文件進行操做嗎？	否
	（２）文件以不正確的方式打開嗎？	否
	（３）文件結束判斷不正確嗎？	否
	（４）沒有正確地關閉文件嗎?	否

3、夥伴代碼簡要述評

夥伴代碼簡介：

    個人夥伴李鑫宇的代碼的主題是論文檢索系統，它所實現的功能以下：

（1）在電腦中建立一個文本庫（文件夾形式，不用代碼）。

（2）輸入要查詢的關鍵字。

（3）當檢索到關鍵字時，打印出文件編號。

夥伴代碼優勢：

※代碼清晰整潔，結構合理

※語法通順，實現相同的功能用到了最簡潔的代碼

※代碼有頭有尾，一鼓作氣

夥伴代碼缺點：

※雖然總體脈絡清晰，可是部分地方格式略亂，須要從新格式化

※由於有修改的痕跡，中間有部分空格

※代碼變量申明不夠明確，判斷變量名花費了不少時間

總結與心得體會：

    審覈別人也是在審視本身，從別人的代碼中看出來的問題，也是本身的問題。雖然咱們寫的是不一樣的代碼，可是在同一套代碼審覈制度的標準下，咱們代碼的問題是相同的。夥伴的代碼清晰簡潔，沒有複雜的功能，僅僅用一個函數就實現了全部的功能，能夠很明顯的看到程序運行的整個過程。可是也暴露出的問題就是，若是一直這個風格這樣寫下去，之後遇到須要屢次重複使用的狀況時，就比較不方便。經過這個嚴重的問題反觀本身，回想一下是否是之前也有相似的狀況出現，答案時確定的。有些時候由於需求很簡單，就選擇了這種直接在主函數裏實現全部功能的方法。經過此次審查代碼，更加了解了代碼的規則，感受本身不只要在算法和功能實現上下功夫，還要在代碼的可讀性方面花時間去改正。一份好的代碼就是一我的對工做，對生活的態度的側面反映，可以面對如今不多部分的代碼能夠作到嚴謹對待，熟能生巧，就能夠在之後的面對項目、課題、工做是駕輕就熟，方便本身的同時也能方便他人。最後，我與個人夥伴李鑫宇同窗的合做從結對，到討論，再到代碼審查工做及博文的發表，合做的都很順利，配合的也是出奇的好，我以爲咱們會繼續合做，圓滿宛城接下來老師交給我咱們的任務。