我系的重課真的是懶癌克星。

一如計組當初的警語：惰怠會導致慘劇。從寒假就抱著一本JAVA從入門到精通回家享樂了...

第一次作業：多項式加減

類圖 & 度量

第一次作業相對簡單，所需的類不多，邏輯上相對容易實現，重點在於正則表達式的學習使用，但是一夜速成JAVA還是正則表達式爆棧了

，雖然在提交之前有測試到這個問題，但已經來不及更改，其他沒有錯誤。

從度量分析可以看到，因為沒有將main()方法獨立成一個類，並且在main()中實例化了其他類，導致快嵌套層數比較高，在小規模的工程中尚可，

但代碼規模一大，即便是在後面作業的三五百行的代碼量，都會因為過深的嵌套，而使得代碼難以讀懂和修改。

第二次作業：傻瓜調度電梯

類圖 & 度量

第二次作業需要實現電梯的傻瓜調度，實現上也不難，這次作業吸取教訓提前一天寫，但你永遠不知道你的debug需要多長時間！！，這次作業雖然

公測全過，但是仍然被查到一個點，原因是判斷同質指令的條件存在考慮不周的狀況，這本該在自己測試代碼的階段查出，然而當時只測試了一些短

的樣例，以及臨界大樣例，不足以充分測試代碼。還有就是對於異常觸發機制的使用並不了解，這次作業中主要基本考慮了所有的情況，而沒有很好

地嘗試使用try-crash機制。

從度量上看，還是存在多層嵌套的問題 ，這個問題其實現在才意識到，設計上參考了課程PPT，但實際上還是按照自己的思路

在寫，在對象的抽象能力上，有待加強，實際上第一、二次編程的思想還是更偏向面向過程。

第三次作業：（A Little Smart）ALS 調度電梯

類圖 & 度量

第三次作業的類圖要復雜得多，需要滿足繼承、多態、接口等編程範式，難點在於ALS電梯判定捎帶條件，此時我在代碼測試上的不足

就體現出來了。這次作業代碼規模要大得多，前期對需求文檔的閱讀理解不足、構思的不全面，都導致編程階段bug的泛濫，不斷測試

短樣例，不斷打補丁，添加限定條件，導致代碼可讀性極差，給debug造成一定困難（自己都不想看自己的代碼），前期的準備很是不

足。然而最大的錯誤，卻是一個低級錯誤，由於輸出的方法從第二次作業的基礎上修改，一些沒有預料到的參數，在特定的情況下會被

輸出，這讓之前的努力白白浪費掉，極其可惜。可見，雖然編程實現上，可以磕磕絆絆把功能實現，但遠沒有能夠完成一個完善的工程，

編程的習慣才是這些問題發生的根源。對於oo這種比較大規模的編程題，如果所有事情推得太後，往往沒有給自己留下後路，也沒法有

充分的時間測試優化自己的代碼，最終提交的版本始終不是自己最滿意的。

代碼度量上看，嵌套問題還在，其他的復雜度之類的尚可。不過再審查別人的代碼過程中，發現他人代碼的風格極好，尤其是之前第二次作業

抽象模塊封裝都要高我不止一個層級，明顯優化過多次，賞心悅目。

自己程序中的bug

有：條件判定不涵蓋所有情況的bug、爆棧的bug、輸出錯誤的bug

主要導致bug的原因是，沒有安排合理的編程時間以及粗心大意，還有就是測試驅動開發的能力不足，實際上多數錯誤不是編程能力上的不足

，而是編程習慣確實有待改進。包括與別人對拍的過程中，也覺得自己由於時間比較緊張，沒有非常仔細尋找bug，而是追求速度。希望下次

真正將心態轉換成真正在編寫一個工程，而不是在趕作業。

別人程序中的bug

前兩次作業中的程序沒有找到bug，第三次程序存在同質電梯請求判定錯誤的bug，而且README基本沒寫，發現別人在細節的處理上更加幹凈

利落，類的劃分更加恰當，即便會有bug，但代碼風格更好，也更加容易找到bug。我想這是代碼量上的差距，需要用時間來彌補。測試別人代

碼主要還是對照錯誤分支樹構造短測試樣例來測試，同時閱讀代碼找bug，但是效率不高，這種方式容易讓人厭煩，應當嘗試編寫腳本自動測試。

心得體會

面向對象編程的思想需要大量代碼的實踐來體會，就目前的感受來看，面向對象編程的思想在多對象交互的情景下非常實用，比面向過程更加容

易理清思路，而在未來的開發中面臨的多數情況基本是多用戶群高並發的場景。看到大佬們對作業的熱情和投入，覺得自己在這門課上的付出似

乎並不足夠，所以下次也要加油鴨。

　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　2018-04-02

oo第一階段總結