OO第一次階段性總結

---

通過三次做業的歷練以後終於來到了寫博客這一週。回顧開學來的這一個月，令我印象最深入也是最累的一門課就是OO了。雖然上學期學過一部分Java，但這學期開學就來的OO做業仍是讓我在第二週就開始熬夜了。不過雖然這幾回做業相比於其餘幾門課在開學這一階段的進度來講感受很緊張，可是我從中學到的知識以及代碼技巧也不少（給別人挑bug也熟練起來了（狗頭））。

前三次做業的度量分析及類圖

第一次做業

第二次做業

第三次做業

由上可見，三次做業中，個人代碼中都存在一些較爲複雜的方法，這些方法大可能是整個程序核心邏輯的部分。在未來的做業中我也將考慮如何減小核心代碼的耦合度。

關於Bug

本身的程序

前三次做業中，很是幸運的是個人程序都沒有被挑出bug。儘管我本身也對本身的程序進行了完整且花樣繁多的測試，但這並不能徹底說明程序中徹底不存在bug（雖然我以爲個人程序是bug-free了）。所以在這裏我打算談一談本身debug的感覺。

前幾回做業當中，我在做業中花費時間最長的就是debug以及尋找潛在的bug。我測試的步驟通常按照

• 分支樹
• 簡單的功能測試
• 複雜一些的功能測試
• 邊界測試以及暴力測試

來進行。其中通常問題出如今複雜功能測試以及邊界測試中。對於複雜的功能測試，找到bug的要點是構造一些足夠特殊的樣例。例如第三次做業中同層捎帶屢次的問題。除此以外還能夠構造一些較長的功能測試樣例，例如讓電梯反覆上下行，以此檢查出潛在的問題。邊界測試部分讓我印象深入的是第一次做業中的表達式，雖然我已反覆確認正則表達式的邏輯沒有問題，但因爲正則表達式一次匹配過長，致使對於很長的表達式出現爆棧狀況，這一點在以後使用正則表達式過程當中都有注意。

別人的程序

這三次做業我拿到的互測樣例中或多或少都有一些bug。我尋找bug基本也按照了測試本身程序的步驟，但在測試過程當中也會經過注意對方代碼中存在的缺陷來構造測試樣例。印象最深入的是第一次做業中的我拿到的互測程序，因爲其使用數組以及簡單的排序來管理整個表達式，輸出前將數組按指數從大到小排序，但輸出時判斷空多項式的邏輯有誤，致使輸出錯誤。這樣的缺陷經過測試樣例尋找，效率並不如直接閱讀代碼來得快。所以在後續測試過程當中我也會仔細注意對方的代碼。
代碼規範真的很重要，但願你們儘可能少用諸如temp1，temp2這樣的變量名來編寫程序，也儘可能多寫註釋，本身看着舒服，測試的同窗看着也舒服

感想

前三週的做業仍是有驚無險的度過了，但我認爲本身的代碼仍有改進的空間。首先是能夠進一步下降耦合度，其次是代碼能夠再寫的可讀性更高一些。固然這些改進措施的前提是須要有充足的時間，而不是趕ddl。雖然在研究一段指導書以後（看完大佬們討論後）再開始編程效率更高，我仍但願之後的做業我能夠儘早開始儘早完成，也但願指導書能夠更加明確。