第一次做業的指導書發下來以後我按着上面的步驟一步一步的作了以後發現項目拉下來了,怎麼開始碼代碼呢...而後在舍友的幫助下才知道怎麼建包建類,而後對Java的語法又不是很瞭解,因而就先把C的代碼寫了而後照着C程序的代碼進行面向過程編程...正則表達式
第一次做業中未熟練了解到正則表達式的用法,因此在分析多項式時使用了狀態機用了不少的if-else也正是這樣因此在互測中被找到了一個多項式判斷的bug,在公測中也因爲沒能徹底理解指導書也掛了一個。互測中對方的bug貌似我比還多他的error用了小寫,這致使他的公測掛了一堆,我得先把公測裏一個一個錯誤樣例看完才能去給他找其餘不重樣的bug,不過仍是找到了數組越界、以及正則表達式錯誤。編程
從度量分析中能夠看出第一次做業寫的代碼圈複雜度很高,由於這是按照C語言寫的面向過程Java,主類有300+行各類循環圈套...但通過第一次做業也粗略的瞭解了Java是怎麼寫的,可是對類之間的調用還不是很明白。數組
第二次做業要求使用5個類,我在寫的時候先是構思了下該怎麼判斷同質,而後決定把每一個類型相應樓層的指令最後的響應時間存入一個數組中並放在指令類型所對應的電梯和樓層類,並在控制器中完成電梯執行指令先後狀態的轉化和時間的計算,並把有效指令運行結果存入動態數組中。雖然在第二次做業中是能這樣寫的,可是這種操做給了第三次做業代碼改寫帶來了巨大的困難。並且在寫完全部類以後在整合這5個類時遇到了類之間沒法相互調用的問題(小菜雞隻會一直new一個類,而後類中數組的數組又得保存,這調用之間產生矛盾),後來在瞭解類之間調用規則以後終於把程序跑成功了。測試
仍是一如既往的圈複雜度超標,雖然此次做業中用到了正則表達式進行格式判斷,可是因爲寫程序時邏輯還不夠清晰,因此感受程序有點繞彎。這搞得本應該很傻瓜的電梯一些代碼顯得不少餘。3d
並且在判斷不符合正則時輸出的錯誤信息忘了加上#號,這致使我公測中有關格式錯誤的點全都掛了。互測時到是沒有被找到bug畢竟此次的電梯比較傻瓜,判斷完同質就能夠輸出結果了,而後也沒有找到對方的bug。在此次做業中我收穫了類與類之間應該如何調用,以及多種調用方法。blog
此次的做業在第二次做業基礎上加入了捎帶功能,本覺得想平常生活中常常搭的電梯同樣,覺得捎帶的原理很簡單。不就是在電梯往目標樓層行駛時有人按電梯,電梯就會停下來嘛。而後看了下指導書給的判斷條件,感受跟本身想的差很少,然而在代碼實現時卻感受到力不從心:捎帶的判斷,捎帶的同質判斷,以及停靠樓層是否該同時完成多個同樓層指令,這些都得考慮到,在初次寫完並能運行後試着運行了幾個簡單的樣例都運行不對...幾乎兩個測試樣例de出一個bug。通過多個樣例的洗禮後,感受才de出了像樣點的程序。然而最後仍是發現了一個de不了的bug——同層完成多個指令時按指令的輸入順序輸出,因爲我每次出隊時都已經把該指令從請求指令中刪掉了因此並不能再判斷誰先誰後,當時想到了設個flag而後改完後發現輸出全亂了,又想不到什麼其餘的靈感,因而就放棄了。在進行互測時,我獲得的代碼邏輯十分的清晰:何時該去同質,何時該把請求從隊列中去掉,他都安排得好好的,而個人代碼是在讀完請求進入循環後再判斷是否同質,這致使原被捎帶請求升級爲主請求後它是同質的就結束了循環致使隊頭請求變成主請求,而本來應該是另外一個可被捎帶請求升級成主請求這樣它就能捎帶其餘的請求,主請求改變後沒法對本應該捎帶的請求進行捎帶,因此輸出結果錯誤,而後還有就是由於這樣一個同質判斷機制而致使同層多個捎帶響應判斷錯誤。我很感謝測試者幫我找到的這些bug。(我本來還覺得本身程序就一個bug了...繼承
圈複雜度超標*3,因爲此次用了多個循環重複遍歷請求隊列來查找可捎帶請求因此致使塊嵌套深度太高,不過這三次做業以來個人代碼貌似逐漸具備凝聚性(大概吧。此次做業中對繼承的使用,以及接口都有所瞭解。接口
這三次做業最後回顧起來感受都不算是很難的那種,但爲何寫的時候卻無從下手呢?究其緣由仍是自身對題目要求上不夠清楚,代碼邏輯不夠清晰,不知道該幹什麼,沒有清晰的一個程序流程圖。這就致使在寫代碼的時候忽然不知道下一步應該怎麼辦,或者是大致上知道該怎麼辦可是細節上卻沒有考慮徹底。對於de本身的bug通常都是先隨便跑幾個寫代碼時腦海中飄過的有必定針對性的樣例。而後再測大一點的數據。而後對出現的問題進行分析。de別人的代碼也是先用本身想到的那些樣例,而後再對其代碼進行研讀,分析其程序代碼流程。並藉此瞭解其代碼中各個數組之類的變量的邊界,並對這些邊界進行邊界測試。當讀懂對方代碼後對方會出現的bug天然也就會被發現。隊列
一、不能趕ddl。基礎
二、不能趕ddl。
三、不能趕ddl。
四、只要認真對待就不會沒有收穫。