非常開心地迎來了OO第一次放松，當我准備安裝好插件，做好圖，弄好數據就來寫博客時，才發現第一步我就過不去了。
安裝AmaterasUML
Amateras是用來自動生成類圖的插件。
教程：https://www.cnblogs.com/xiluhua/p/6667935.html
當我一切都按教程做了，理直氣壯地點開New ——> Other，並沒有教程所說的class diagram，連個Amateras的folder都沒有。我一度懷疑我eclipse重啟得不夠給力，多次restart甚至重啟電腦。
如果你也是這樣，試試我找到的偏方吧：
解決方法是：
1、打開命令行，到當前eclipse的目錄下，輸入eclipse -clean，重新啟動eclipse，這樣eclipse就會加上新插件了。
2、如果插件不能升效，則請將eclipse\configuration\org.eclipse.update目錄刪除后再啟動eclipse:)你可以在eclipse的菜單"Help"-->"About Eclipse SDK"-->"Feature Details" 和"Plug-in Details"中看到新安裝的插件。
然后你再看看New ——> Other，就可以快樂地創建class diagram了。
安裝Metrics
Metrics是基於度量分析代碼的插件。
教程：https://blog.csdn.net/u014736978/article/details/41149767
但是！，但是！在安裝之前，要確認一下自己的是eclipse3.X，如果你使用的是助教給的eclipse，是使用不了Metrics的。所以還是去官網下個最新版本吧~
以上是一點安裝時遇上的坑，下面來分析自己的代碼。
代碼分析
第一次作業
度量分析
類圖
第二次作業
度量分析
類圖
第三次作業
度量分析
類圖
對於度量的分析
這里對標紅的McCabe Cyclomatic Complexity和Nested Block Depth進行分析。（標紅表示超出范圍）
McCabe Cyclomatic Complexity 表示圈復雜度，圈復雜度用來衡量一個模塊判定結構的復雜程度，圈復雜度大說明程序代碼可能質量低且難於測試和維護。第二和第三次作業造成圈復雜度過高的原因均為調度器類中的schedule()方法。個人判斷是我的代碼的schedule()方法承擔的職能過多，不僅要去除同質請求，還要選擇可捎帶請求，最后還要將請求排序形成可執行隊列，對同質請求和可捎帶請求的判斷使用了過多的if判斷語句，每個if判斷條件也並不單一，導致了schedule()方法的圈復雜度過高。
Nested Block Depth表示嵌套塊深度，嵌套深度表示if或者for或者while循環嵌套的個數。這里的嵌套塊深度過大同樣來自調度器類的schedule()方法。由於在形成可執行隊列的時候對同質請求和可捎帶請求同時做了判斷，導致了過多的if語句和while循環多層嵌套。
其實這兩特點在debug的時候已經能體會到了，過高的圈復雜度和嵌套塊深度使得debug並沒那么好受。
自我評價
優點：總……總得寫出點優點吧。
1.對於請求的解析，我分為了兩個部分，一是請求類的自我判斷，二是電梯類和樓層類對請求內容的解析。另外，每個類的在程序中的職責划分還是很清晰的。
沒有序號2了。
缺點：
1.初次接觸面向對象編程，對於類的划分總與現實分不開。想用電梯類和樓層類解析請求源於想模仿電梯和樓層向調度器發生請求，於是又給電梯類增加了一個構造器。這樣一來似乎使得電梯功能過於復雜。實際上，應該增加一個Inpu_Handler類來處理輸入信息。
2.對於請求隊列中同質請求和可捎帶請求的判斷，我都置於調度器中，使得調度器過於臃腫，並且在判斷過程中又由於需要不斷為調度器增加屬性和方法，使得調度器越來越復雜。或許可以增加一個類用於篩選請求隊列，再將可執行隊列傳給調度器。
3.能力不足，在設計的時候未能考慮到代碼的維護與可擴展性。於是從第二次到第三次作業的過渡中還是出了不少問題。
OO三次作業以來，在各個部分花的功夫可以說是debug的時間 >> 划分類的時間 > 看指導書的時間 > 寫bug的時間 >> 0。對類的划分仍然需要加以斟酌，使各個類的方法和屬性更加明確，平衡各個類的負擔。
有一個很深刻的教訓就是，當覺得類的方法實現起來過於復雜過於長時，應該考慮一下是否讓它承擔了太多，而不是一味地在類中添加屬性和方法，寫的時候“算了，不管了，我就這樣寫”一時爽，等寫完之后看着自己丑陋的代碼和蹩腳的划分，重構的念頭就開始萌生了，連提交的勇氣的沒有。
關於bug
自己程序的bug
1.第二次作業的程序被找出時間順序判斷不正確的bug。
測試樣例：
(ER,1,0) (ER,5,100) (ER,1,0) RUN
在寫代碼，不對，在寫bug的時候，很天真的把開始判斷時間順序是否不正確的起點設置為請求發生的時刻是否為0，而不是該請求之前是否有正確請求。
改正之前：
if(floor_req.getTime() != 0 && floor_req.getTime() < this.queue.get(this.queue.size()-1).Time) { //floor_req表示樓層請求，queue是請求隊列
改正后：
if(this.queue.size() != 0 && floor_req.getTime() < this.queue.get(this.queue.size()-1).Time) { //floor_req表示樓層請求，queue是請求隊列
2.第三次作業公測時間超范圍的樣例未通過。
測試樣例：
(FR,1,UP,0) (ER,1,23333333333)//我已經感受到來自它的嘲笑 RUN
按道理這個對時間超范圍的判斷第二次作業通過了，第三次應該不成問題。並且截止日的前一天晚上還對多種輸入不符合要求的點進行了測試，並沒有發現問題。
程序員再一次遇到了靈異事件，T.T在公測結果出來之后，我的內心—— “我沒動啊！”，“昨天晚上還是對的呢！”
於是發現在進行判斷的時候出現了邏輯漏洞，難以解釋，單獨判斷時間是否超范圍時會出錯。
寫bug有風險，重構需謹慎。
找別人程序的bug
1.首先把所有符合評測要求的樣例跑一遍，一般來說，是不會出現bug的；
2.嘿嘿嘿，然后就開始無賴的暴力了，把輸入限制的參數100改成50000，用大樣例RUN一下，把輸出結果和自己的輸出結果進行比對，這是找到bug最快速的方法之一。當然你不能保證自己的輸出結果完全正確，萬一比對之后發現的是計幾的bug，周四晚上的覺是睡不好的，如果是別人的bug，則需要在100行內構造出他會出錯的測試樣例；
3.開始認真看代碼，首先摸清楚代碼整體的邏輯，然后看一些自己寫過的bug是否在這也會出現，最后分析對方代碼是否存在一些邏輯漏洞，比如正則表達式是否正確，臨界時死循環，數組下標溢出等等，並為此精（驚）心構造測試樣例。
心得體會
1.關於設計，其實很大程度上仍然沒有擺脫面向過程的思想，在對類的設計中，更多地是關注這個類需要在整個控制流程中需要做些什么，而不是這個類本身自擁有的方法和屬性。但其實大部分人都是一樣的，思想的過渡不是一次多項式加減的作業就能完成的，還是需要多加練習和總結教訓。應該先從類自擁有的屬性和方法出發，去構造類之間的聯系，先畫好圖再寫代碼。
2.第三次作業相信大家都對“神奇的bug無處不在”深有體會，盡管兩個人校對完100行的樣例都一模一樣，當測試30000行的樣例時，輪流debug的場景就出現了，當30000行樣例校對完之后，新的樣例又會讓兩人開始輪流debug。指導書老長老長的統一規定自身就帶有復雜而難理解的邏輯，如果寫代碼之前沒有把邏輯流程圖理清楚，這個bug真的難殺。
3.從我拿到的作業來看，第二次拿到的作業模擬了時間0.5s、0.5s地進行，第三次拿到的作業則一條一條請求地進行尋找，對循環結束條件也不加以時間約束。雖然在構思程序之前這都是我所想嘗試的，但個人更加追求程序運行的速度與性能，雖然這樣自然而然地也給程序增加了邏輯復雜度，但一兩秒跑完幾萬行的樣例與十幾秒跑完，我還是更青睞前者吧。希望能夠和大家在程序設計和算法構思方面多多交流。
4.關於互評，互評水深，從我第一次被別人掛上一個交的是.cpp文件而不是.c文件的crash就體會到了。個人認為互評除了找到公測未能發現的bug之外，readme確實是很重要的部分，只要不是很牛角尖的摳readme都是可扣分的選項，所以在readme上也是需要花一定功夫的。關於程序的異常處理，我兩次拿到的程序都沒有進行異常處理，報告的bug還被助教刪掉了，emmmmm至少意思意思的try和catch一下？
try{ //-------code------ }catch(Throwable a){ //to deal with }
如果有什么說得不好的地方，有什么建議和意見，歡迎大家評論指出~
嘻嘻，希望大家一起加油，干干干干干！