使用了masteruml插件來生成類圖和metrics插件分析代碼 第一次作業 1、UML類圖 >在第一次作業中，使用了兩個類,代碼中有沒有使用的變數與函數，為平衡兩個類的內容，我將輸出函數放在了多項式類中，但是仍然不夠平衡。 2、量化分析： >處理字元串輸入的過程，按照面向過程的思路來寫，嵌套的判 ...
使用了masteruml插件來生成類圖和metrics插件分析代碼
第一次作業
1、UML類圖
>在第一次作業中，使用了兩個類,代碼中有沒有使用的變數與函數，為平衡兩個類的內容，我將輸出函數放在了多項式類中，但是仍然不夠平衡。
2、量化分析：
>處理字元串輸入的過程，按照面向過程的思路來寫，嵌套的判斷條件過多，時間空間複雜度都比較高，寫的並不簡潔。
3、程式中的bug：
公測bug：壓力測試，在數據量較大的情亂下，我對計算結果進行了取模運算，導致了公測出錯。錯誤來源處於多項式計算的過程中，在最終獲得運算結果並存入結果數組中，為了保持與輸入相同的最多六位數的要求，我對結果進行了取模運算，這與程式中類的設計沒有太多關聯。
被髮現的bug：對於一種特殊情況（指導書沒有說明）沒有在Readme中說明的incomplete錯誤。這次bug提示我，一定要好好寫readme，儘可能的覆蓋程式的所有邊界情況，防止出錯。
自己的程式還是存在問題，在輸入時沒有限制輸入的最多數目，將數組開成了100大小，且數組的操作並沒有包括在trycatch代碼塊中，如果多項式個數非常多，程式會出現crash
4、分析別人bug的方法：
分析別人bug的方法，首先，我將我自己的測試用例都嘗試了一遍，結合其指導書上 的要求，找到了其未處理指數為負數的bug（同時也說明公測並沒有涉及到這個問題）；其次，我閱讀了TA的代碼，在代碼中，負責處理輸入的模塊並不是由正則表達式來完成的，在抱著感興趣的態度閱讀了與正則表達式不同的有限狀態機的實現過程中，畫出了流程圖，並找到了在有限狀態機過程中存在的一個計數錯誤問題（多項式超過50項仍能計算）和一個輸出錯誤問題。我的測試過程是，首先測試了幾個壓力測試，然後將我在編寫程式時用到的測試樣例，可能出錯的點進行了測試，最後看代碼中會不會出現問題。
5、心得體會：
在第一次作業之前，只使用java編寫過一個簡單的商店管理系統，但是第一次作業寫的仍然不夠OO。主要的代碼都在Computeploy類中，兩個類並不均衡。輸入部分，採用正則表達式進行判斷是否滿足要求，為了防止爆棧，將正則表達式進行了兩次拆分；計算部分，我參考了C語言，寫的比較面向過程，採用比較傳統的字元串處理來處理數據，然後進行計算，對result多項式進行輸出。
優點是，對數組進行存儲的時候比較方便，可以直接使用；正則表達式分成了兩個；在ploy類中實現的列印方法，相對來說更加均衡
缺點是，空間利用率不高，數組開的比較大；沒有考慮到超過最大限制數目多項式的存儲問題；計算過程偏向於面向對象；正則表達式容易出現爆棧現象。
第二次作業：
1、uml類圖：
>將電梯與樓層抽象出來，用request和requestarray來分析請求，最終串在調度器類中；但是有個失誤，就是電梯的運行過程比較簡單，所以將調度方法寫在了電梯類中，這也直接導致了第三次作業無法使用第二次代碼。
2、量化分析：
>這此作業還是在處理字元串的方法上篇幅過重，查了一下Mccabe Cyclomatic Complexity的含義，用無向圖的方式來分析結構複雜度，然後看到了自己的三分代碼都爆了紅，道阻且長。
3、bug：
公測bug：由於處理輸入時採用的先讀取進隊列，再進行判斷的方法，導致與要求的直接判斷方式不符，導致了四個點錯誤；另外兩個點的錯誤都是在0時刻同質請求的忽略，在判斷同質請求時的判斷語句沒有寫好，將所有0時刻的請求都判斷為了不同質。
被髮現的bug：還是Readme的問題（emmm），由於對OJ期望輸入的不瞭解，我在寫Readme時，#後面輸出了詳細的錯誤信息；但是在OJ輸入樣例錯誤之後，我在代碼中將#輸出代碼註釋了（emmmm）但是沒有同步進行Readme的修改，然後被報了錯誤，還是Readme的問題。
4、心得體會：
這一次的作業，從指導書來看，面向對象的思想還是有的。但是在實際的代碼編寫過程中，還是有很多編寫面向過程的思維想法。在整體的編寫過程中，我將其中的request和requestlist類用讀取輸入時請求隊列的生成，在這兩個類的實現過程中，我忽視了在請求未進入隊列就進行判斷正誤的操作，使得在公測時部分點因為ERROR的輸出順序有誤出現了錯誤；在Lift類，我構建了電梯常見的10層停靠按鍵和run方法，雖然這個調度方法應該在Scheduler類中進行編寫，這裡也是一個沒有設計好的典例。在我的設計中，我類比真正的電梯，模擬電梯和實際樓層，我覺得這是實際設計時比較好的設計模式。但是，對於調度器這個抽象出來的行為，我並沒有設計好。其次，在測試的時候，我遺漏了初始值為0時的同質請求的判斷。
其次就是對OO課程時間安排上的反思，由於周末事情比較多，我開始寫電梯的時間比較晚，導致最後的Readme還是存在部分空缺，不夠完整。於此同時，需要吸取的教訓是，在git上不同版本對應的文件需要實時更新才行。
第三次作業：
1、uml類圖：
>沿用了第二次作業的基本架構，但是簡化了電梯的功能模塊，主要的調度器功能都寫在了調度器類中，並且分了好幾個方法來防止單一方法過長，這種做法在進行debug的時候省了比較多的功夫，簡單的一行sysout輸出就可以判斷是那個模塊出了問題；但是在debug的時候，沒有想著調增代碼結構，只是在原基礎上增加，導致代碼過長。甚至出現了低級錯誤.....
2、量化分析：
>如前面所說，調度方法在設計的時候沒有考慮到很多的代碼，也沒有重構，這兩個指標表現的還是很差。然而現在並沒有什麼代碼重構的經驗，還是要在接下來的coding中多積累。
3、bug：
公測bug：由於一個很蠢的錯誤導致的公測沒有過一個點，想來也是有趣（呸），在看到每次輸入的多行請求只能以(1,FR,1,0)開始，我很快將其單拎出來處理，然後少輸出了一個/符號，導致公測全部沒有通過。
4、心得體會：
首先，這次作業將我的毛病表現的很明顯。最重要的問題，粗心大意，在吸取了第二次作業沒有看討論區的教訓，對討論區中出現的詳細描述都進行了排查和debug，但是每次都遺漏了第一行的輸出信息，導致了悲劇的產生。其實，仔細想想，細心這個問題一直很困擾我，在計組課程中，也因為一個非常微笑的bug導致了一次測試沒有通過。這是我這次作業無效收穫的最大的教訓和經驗。
其次，在debud的過程中，我也意識到了一次只解決一個bug的弊端（或者說，痛苦）。在debug的過程中，感覺就像是在一個修補一個破爛不堪的花瓶，這裡需要打洞去填補，之後會導致其他的地方需要重新修補，反覆進行。這從側面表現出了一個好的設計從一開始就提供的優勢。最近，我在讀《重構》這本書，雖然我只看了前三章，但是第一章的案例開始看的時候，我覺得寫的挺好的（捂臉），但是作者從變數名到類的結構再到每個類之間方法與代碼量的平衡，提出了很多很多的意見。移除暫時性的變數，改變每個類中的方法的具體位置。在這次代碼中遇到的debug難度與大工程大項目的debug難度完全不能比，如此多人共同協作的大項目也應該更難吧。在本次代碼中，Scheduler類的長度明顯過長，按照重構的要求來看，還需要很大的工作量。
再其次，這次的測試程式做得並不夠，測試程式應該覆蓋的越全面越好，但是這次連最基本的錯誤都沒有發現，需要反思。
再再其次，由於第二次作業將調度器寫在了電梯類中，導致了第三次作業無法按照要求按照繼承機制重寫調度器方法，介面類與toString在設計的時候也並沒有發揮本質的作用。
總之，這次作業寫的十分失敗，十分失敗。熬夜並沒有換來好的結果。
接下來的展望
多線程的挑戰也已經到來了，現在還領略不到面向對象思想的精髓。找時間看完《重構》，結合幾個小例子，爭取在後面的作業中進行一些實踐，或者課程結束後，把自己寫的這些雜亂不堪的代碼給重構一下。細心，比什麼都重要。
