oo第一次博客做業

程序結構分析

第一次做業

度量

　　

類圖

第二次做業

度量

      

類圖

   

第三次做業

度量

　　

類圖

　　主方法寫在了調度器裏，調度過程實際在request，故重構了request

　　這個構造方法其實仍是有部分的面向過程思想，而且電梯類並無保護到數據。

bug分析

第一次做業：

　　因爲使用了狀態機，寫的很長很難看，產生了不少bug，改來改去總共提交了七八次。

　　被公測和互測掛了很多點，也對本身的程序進行了分析，由於開始沒有支持多項式最前面的符號，後期時間緊急改了改，而後就把多項式之間的計算搞亂了。特徵很明顯，符號形成的錯誤，錯誤出在輸入的類裏面，直接致使了後面計算的錯誤。

　　程序過於面向過程，有待改進。

第二次做業：

　　重要的是天天寫了一點，時間比較充足，測試也很充分，並無出現bug，而且保留了測試集對互測程序進行了測試。程序設計仍是有些不足，怎感受類的使用很牽強，沒有認識到數據保護的重要性。

第三次做業：

　　未出現bug。相比前兩次做業結構上更完善(雖然依舊很渣)。

分析bug採用的策略

　　(仍是不但願你們喪心病狂，無所謂的錯誤就放過好了）

　　(1)使用保留下的數據集，這能夠做爲一個基本的測試。對於易錯的點，相信你們內心仍是清楚的。

　　(2)臨界條件必定要測試，必定要測試，必定要測試！！！不管是自測仍是互測，臨界條件極容易出bug。

　　(3)若是公測有錯誤點，分析一下錯誤緣由，也可能找到其餘bug。

　　(4)既然拿到了程序，就看一看你們的程序結構，對於本身寫程序有利，也容易發現一些問題。

　　(5)buggy oo上面的有些數據很好，也能夠相互之間對拍。

心得體會

　　代碼風格要好，寫清晰，不然後期很難debug。

　　設計中能夠把肯定沒有bug而且不會頻繁改動的部分包裝。

　　寫程序前，最好先有個簡單的框架構想，或者互相討論，對一些難點交流下設計思想。

　　做爲並無系統性學習java的一員，在這幾回做業中逐漸體會到了java的編程思想，從第一次做業面向過程，到如今終於像個樣子。

 

The end:

　　oo羣裏的消息要常看，你們不時會發個樣例，問個指導書上不清楚的點，理解好指導書要求這個程序就不會反覆修改屢次。

　　本身有什麼問題要及時與助教交流溝通，每一個人理解方式不一樣致使斷定也很難去規定。

　　readme對於自定義的部分要寫清楚，我的信息刪仔細。

　 但願你們能在後期的學習中更上一層樓。