一、基於度量來分析自己的程序結構

第一次作業：

C語言部分：

　　由於很久沒有寫C語言代碼，寫起來還稍有生疏，在字符串處理獲取多項式信息的功能中花費了很多時間，這也與後面Java中的字符串對比形成了鮮明的對比。

　　體會：代碼必須經常寫，要不然會手生的厲害！

Java部分：

　　之前接觸過一點點Java，一些經典算法基本能實現。開學前在菜鳥教程上頁提前做了一點小小的預習，談不上了解，但是大概知道講的是什麽了。加上上課的時候，紀導講的也挺清楚詳細，第一周的作業雖然陌生但也有驚無險。真正上手實踐和看教程還是不一樣，光是進行構思就花了不少時間，思考如何“面向對象”地實現功能十分費時，反而具體實現功能的時間並不多。構架參照了老師PPT上的結構，同時也添加了一些新的東西。但是由於對於Java這門語言的確不了解，其實是寫了很多無用代碼的。起初正則表達式的使用並不熟練，反而在我拿到的互測作業中獲取了不少知識。比如Pattern和Matcher的使用，可以利用Matcher.find和Macher.group獲取匹配的字符串，減少字符串處理的復雜程度。另外關於正則爆棧本也應該是提前想到的事情。

　　體會：enum很好用很直觀！結構設計很重要！要理解Java中的類變量的本質是指針！

第二次作業：

　　第二次作業就已經進入了面向對象，比較直觀的感受就是指導書的復雜。大概用來理解笑話指導書所想要表達的意思的過程占據了整個作業周期的1/3。最後也是在和幾位同學的交流討論中慢慢的理解了要求。不過在理解了要求之後，有了第一次作業的一邊摸索一邊寫作業，這一次的寫起來思路還是清晰的。

　　體會：理解題意十分重要。

第三次作業：

　　不得不說第三次作業對於理解能力的要求進一步提高。我知道周一晚上才能想清楚大概的思路，周一周二連著兩個晚上熬夜才最終解決。另外不得不說這一次的測試數據起到了至關重要的作用，同學的測試數據幫我找到了至關重要的BUG。但是這次的作業的復雜性讓我的代碼復雜度驟然攀升。有很多地方出現了冗余不說，為了實現一些feature不得不設計了一些很醜的代碼，甚至到最後我自己都不想看自己的代碼。下手前的設計步驟的重要性不言而喻。由於讀題不認真，甚至還出現了要求沒有看清的情況，好在最後臨截至罐頭及時改正。

　　在這次作業中，由於必須同時執行多條指令按照輸入順序的要求不得已在Elevator類中設置了緩沖隊列，根據後面的輸入才決定執行的情況。這個結構其實不盡合理很可能會給後面的多線程帶來麻煩，需要及時重構修改。

　　體會：良好完備地本地測試是通過公測的基礎。必須看清要求的每一個細節。

二、分析自己程序的bug

第一次和第三次中得益於提前進行了大量的本地測試均未被扣分。第二次中發生了一些小的失誤，關於空行（只用空格或直接回車）的處理我的第一版中進行的處理是當作非法輸入進行報錯，後由於測評機不能識別前導空行，將設計改為忽略空行，但是對於readme的更改雖然上傳至gitlab，但是沒有即時拉去到OJ上導致了readme和實際行為的不一致。不過後來經測試者提醒，空行作為錯誤輸入似乎是被規定為無效輸入了（不過我是沒有看到，這也體現了看消息的重要性。

　　對於課下的bug最重要的還是理解清楚題目要求，同時考慮清楚邊界條件。理解錯題目的意思，很可能給後期改代碼帶來巨大的麻煩。而邊界條件則是任何時候我們都必須註意的事。

三、分析自己發現別人程序bug所采用的策略

　　第一次作業，由於該同學的輸出格式不對，公測過的點數不多，不過由於公測不強，關於計算，我還是找到了不少bug，比較直接的錯誤原因還是邊界情況考慮得不夠周全。但是由於對於OJ使用的不熟練，我有兩個bug其實是給錯了的，寄希望於被測試者申訴來取消bug，但是可惜被測者最終未進行申訴。借此也希望後臺學長們盡快加入撤回bug的功能。

　　第二次的同學作業無懈可擊，我還其中獲得了一些啟發。

　　第三次作業的同學也十分優秀，算是我見過的最“面向對象”的代碼，但是我再閱讀readme時發現了他的代碼和readme存在行為不一致，因此提出了bug。

策略：

　　1） 我自己的數據測試一遍，對於大佬基本無效。

　　2） 根據readme說明測試邊界數據，有時候有效。

　　3） 閱讀代碼構造bug，更多時候讀不懂，但是能學習到很多。

四、心得體會

　　1）學會用工具debug還是很重要的，現在的代碼規模已經不像是過去c語言和數據結果的代碼量了，不能高效的使用debug工具非常影響效率。

　　2）大學的各種考試包括作業都有信息戰的趨勢，構造或拿到一份好的測試集往往就能救人於水火之中，能不能關註到Issues的信息也是成敗的關鍵因素。指導書的更改和通知群的消息都是十分重要的。磨刀不誤砍柴工，有時候先進行足夠的思考，看完所有的Issue和群裏的問題再下手，可以減少寫代碼的時候要求不明確時帶來的反復修改，也降低debug的難度。

　　3）還是要嚴謹。Readme之於程序就像說明書之於電器，如果readme和電器實際的操作不一致，顧客是不能接受的。不管程序還是readme都應該盡量做到完備，而不能應付了事。

　　4）git其實還沒有真正利用起來，以後應該加強對於git的學習和運用。

　　5）現在的代碼其實還遠遠不夠簡潔，很多由於需求增加而臨時設置的變量或者其他冗余內容。模塊化做的也不好，應該找時間進行代碼簡化甚至代碼重構。

　　6）在與大佬的代碼進行了比較之後，發現自己在代碼規範還有差距，可讀性應該進一步提高。同時對於拿到好的代碼不光要查bug，更要吸收借鑒，拿來己用。

Object Oriented個人總結第一彈