oo第一次總結

第一次做業

1.度量分析

 

 第一次做業的metrics圖分析出現了標紅的McCabe Cyclomatic Complexity和Nested Block Depth。McCabe Cyclomatic Complexity表示圈複雜度，而Nested Block Depth表示嵌套深度。標紅的McCabe Cyclomatic Complexity代表類之間的職能分配不均勻。由於是第一次寫做業，從始至終都只建了一個類，致使了一個類承擔了全部的職能，圈複雜度出現了超標現象。標紅的Nested Block Depth則表示嵌套現象嚴重。因爲暴力的一次次匹配，不停的用if-else語句和while/for循環語句，致使嵌套不少。

2.類圖

 

第一次做業，由於剛剛學習JAVA，對類和對象的概念不熟悉，基本按照過程化的思惟去寫，因此只寫了一個類。在這個類裏，進行了全部的操做，致使這個類很是的冗雜。

3.關於BUG

第一次做業，要求用面對對象的思惟去看待問題，思考問題，解決問題。可是因爲長期的面向過程編程，致使在寫本次做業的過程當中，很不習慣。第一次做業是多項式的加減法，整體的設計難度不大，可是其中牽涉不少的細節問題。在公測和互測各出現了兩個BUG。公測中的兩個BUG分別是由於正則表達式過於冗長，致使爆棧和前導零輸入太多報錯。公測的這兩個問題，反應了思考還不夠嚴謹，沒有想到會爆棧。互測中的兩個BUG則是由於在Read裏沒有說明嵌套輸入會報錯，即便實際操做中會看成一個輸入錯誤輸出和沒有定義輸入爲{}時，輸出什麼。互測中的兩個問題，反應了沒有仔細研究各類輸入輸出的分類。

而做爲測試者，拿到的程序公測全過。因此想到了輸入和輸出的問題，分別找到了兩個問題，一個是隻輸入{不報錯，以及在輸入的末尾多一個「，」不報錯。綜合來看，第一次做業的輸入輸出是一個難點，很容易少考慮狀況。

第二次做業

1.度量分析

 

 從第二次做業的metrics圖能夠看出，出現了與第一次做業一樣的問題，圈複雜度超標和嵌套現象嚴重。由於所寫的調度的類中，承擔的職能太多以及輸入和調度頻繁的循環判斷。

2.類圖

 

 

 從類圖能夠看出，調用關係有點複雜不明確，由於寫的時候沒有考慮清楚各個類的方法，在寫的過程當中，強行放入了一些方法，致使最後對類的考慮不明確清晰。在之後寫做業的過程當中，會仔細明確的劃分類。

3.關於BUG

相比於第一次做業的主要是輸入格式的錯誤，此次的問題則主要是沒有考慮到數據溢出的問題，致使公測中與數據溢出相關的兩個測試均出錯了。而互測則沒有被發現BUG。

做爲測試者，在拿到的程序中，發現了一個與輸入有關的問題，在正確的輸入後添加字符，不會報錯。

第三次做業

1.度量分析

 

 從第三次做業的metrics圖能夠看出，出現了與前兩次做業一樣的問題，圈複雜度超標和嵌套現象嚴重。一樣是由於所寫的調度的類中，承擔的職能太多以及輸入和調度頻繁的循環判斷。而且由於第三次做業是在第二次做業的基礎上加入了捎帶操做，致使問題更加嚴重，程序更加臃腫。這三次的做業，都反應了程序封裝和代碼簡潔的重要性。

2.類圖

 

從類圖能夠看出，第三次做業類的調用關係比第二次做業更清晰明確。可是思路依然有些不清晰，對每一個類的職能的考慮須要更詳細。

3.關於BUG

對比傻瓜電梯，捎帶問題顯得難度上升了不少。所以若是對捎帶問題看的不全面深刻，很容易出現BUG。正是由於如此，此次公測中出現了2個BUG，互測中出現了4個BUG。公測中的兩個BUG，分別是副請求時間==主請求開關門完畢時間不捎帶和e.sta==DOWN的部分應該在主請求處理完後，選隊列位置最前的成爲主請求。而互測中則主要是e.sta==STILL和e.sta==UP問題。此次做業出現了不少問題，反映了對問題分析不夠深刻，致使程序設計不統一完備。

而做爲測試者，這次拿到一個全過的代碼，因此從一條條BUG樹類樣例去測試，但都沒有找到這份做業的錯誤。

心得體會

1. 到目前，寫了三次做業，對面向過程編程和麪向對象編程的區別的感覺仍然不夠深刻。體會到了它們之間的差別，但還不夠。
2. 這三次做業寫完後，都出現了不少的BUG，致使投入大量的時間去處理解決。緣由是設計思路不清晰有遺漏。因此之後須要把整個程序的思路想明白想清楚，對每一個類的職能作明確的劃分。
3. 關於時間的分配和使用上，作的很差。每次都是拖到週一開始作，致使時間很緊，不得不熬夜。因此之後應該儘早開始寫做業。
4. 這三次做業尤爲是第三次做業，反應了對細節問題考慮的重要性。在思考過程當中考慮了最廣泛的狀況，卻遺漏了一些特殊狀況。之後，在寫代碼的過程當中，應該考慮這部分代碼可能出現的各類狀況，予以分析和解決。