OO第三階段總結

一、 規格化設計的發展

我認爲規格化設計的需求主要來源於在軟件與互聯網行業飛速發展下，工程隨着代碼量的增加，每每會顯得異常的臃腫，難以閱讀。這爲多人合做的工程創造了巨大的不便。而在這樣的背景下，你們都認爲代碼風格的統一和良好編程習慣的養成是及其必要的。可是仍是會在在閱讀和理解代碼時使用不少的時間，所以對規格的需求就不可避免。

二、做業BUG

第十次做業被申報了兩個規格bug。

第一個是因爲以前須要實現刪路功能，我在設計後期，在Map類中添加了一個屬性用以記錄關閉或開啓道路的次數，但在代碼的添加時忘記了修改關閉道路方法的規格中的Modified屬性。

第二個是因爲以前須要實現紅綠燈功能，在某個類的構造方法中添加了this.lightCtrler = lightCtrler;這樣的語句可是沒有修改規格中的Modified屬性。

全部做業均沒有被申報功能bug。

三、規格改進

改進前：

/**
* @REQUIRES: None;
* @MODIFIES: None;
* @EFFECTS: \result == hash of this req;
*/
@Override
public int hashCode() {
    return Objects.hash(src, dst, rqTime);
}

改進後：

 

改進前：

 

改進後：

 

 

改進前：

改進後：

 

四、分析功能bug和規格bug的彙集關係。

未被查出功能bug，規格bug每每是因爲中途更改需求以後忘了改規格而致使的。這體現了我在設計初期沒有全面的分析方法的功能需求，致使實現後續功能時忽然發現這個方法應該修改。

五、心得體會

這三次OO做業大大地提高了個人工程能力，不管是在編碼上，測試和debug上，我都有了長足的經驗，能夠遊刃有餘地實現添加的功能，對繼承的運用也變得更加熟練，理解上也深了一個層次。

因爲測試者擡了一手，沒有仔細找我程序的bug，多是因爲本次做業測試比較困難，黑箱測試會很耗費時間，必需要讀代碼，因此不少測試者都使用了摸魚測試法，好比說我本身。（事實上我認爲雖然個人程序已經較爲完善，但仍是頗有可能出現一些遺漏的地方）