一、三次作業總結
三次作業難度逐層遞進，逐步幫助我們入門理解面向對象思想。第三次作業可以算是系列的巔峯版，因此本文重點介紹第三次作業的設計思路，當然前兩次作業也進行了較細緻的介紹。另外三次使用的查找bug方法較爲相似，統一放在最後介紹。
1、 第一次作業
1.1 需求分析
本次作業需要完成的任務爲簡單多項式導函數的求解。
運算法則包含加法和乘法，因子也只包含常數項和變量項，較好處理。
1.2 實現方案
1.2.1 宏觀架構
這次作業我設計了兩個類，分別是最基礎的Poly類，儲存表達式按[+-]區分的每一項，另一個是包含Poly類構成的arraylist的表達式類。設計說明見下圖
1.2.2處理細節
本次表達式相對簡單，但是因爲輸入字符串過長（200字符），用基於回溯的正則容易出現爆棧的問題，因此本次我進行了修改，去除了一開始使用大正則的思路，採用了循環處理的方法。即每次提取最靠前的項看是否匹配，然後刪除最開始匹配到的部分，繼續匹配。
另外，爲了追求方便，我在開頭進行統一特判，確定空格沒有導致格式問題後去除空格，以便簡化後續的處理。因爲思慮補全這最後也導致我在互測的時候付出了慘重的代價，這個後續再說。
最後的優化中我採取了最基本的合併同類項思路，遺憾的是我沒有考慮到將正項提前這件事，最後強測分沒有滿。
1.3 本次作業暴露的問題
1.3.1 測試問題
本次作業強測全對，互測有一個同質bug被抓。去空格時沒有考慮到“x^+ 2”屬於非法情況，即漏了"\\^[+-]\\d"這種非法情況。這也提醒我在接下來特判的過程中使用枚舉記錄的方法記錄所有的信息，並使用手寫腳本檢驗特判正確性。
1.3.2 結構問題
這次作業因爲整體設計過於簡單，個人感覺我的代碼還是較爲符合面向對象的設計需求的。結構沒有太大問題。
1.4 本次作業的UML圖和相關參數
UML圖
參數分析
2、 第二次作業
2.1 需求分析
需要完成的任務爲包含簡單冪函數和簡單正餘弦函數的導函數的求解。
運算法則包含加法和乘法，因子除了常數項和變量項，還包含了三角函數項，爲處理增添了難度。
2.2 實現方案
2.2.1 宏觀架構
這次作業我設計了三個類，分別是最基礎的Poly，derivate類，儲存表達式類按[+-]區分的每一項，另一個是包含Poly類構成的arraylist和Derivate類構成的arraylist的表達式類。設計說明見下圖
2.2.2處理細節
本次表達式複雜了些，但大體思路與上次接近，我仍採用了循環處理的方法。即每次提取最靠前的項看是否匹配，然後刪除最開始匹配到的部分，繼續匹配。
另外，爲了追求方便，依然在開頭進行統一特判，確定空格沒有導致格式問題後去除空格，以便簡化後續的處理。
在最後的優化過程中，我使用了下列技巧：
1、合併同類項
2、將正項提前
3、將a*cos^2*k+b*sin^2*k進行提取，進行一定判斷化簡爲
2.3 本次作業暴露的問題
2.3.1 測試問題
吸取了上一次的教訓，本次在特判空格的時候思維更加縝密，最終無論是強測還是互測都沒有被發現問題。
2.3.2 結構問題
這次作業設計其實事後看已經開始給第三次作業做鋪墊，變得複雜起來。本次作業其實已經可以使用繼承和接口技巧來簡化設計，但從上面的宏觀設計圖就可以看出我並沒有使用接口和繼承等技巧，導致最後的設計變得十分不簡潔，不合理。很遺憾我一開始設計的時候沒有考慮前面，沒有把握住Poly類和Derivate類的共性，誤以爲兩個類差別很大，導致最後產生大量冗餘設計，IDEA上產生大量黃線（代碼完全複製導致），修改優化起來也變得複雜。
2.4 本次作業的UML圖和相關參數
UML圖
參數分析
類
方法
分析：從參數圖可以看出函數耦合程度過高，類也有很多重複嵌套，設計的並不是非常合理。我直到進行博客分析的時候才意識到這個問題，發現好多時候不應該直接把原始字符串扔進構造函數處理.....好吧，下次注意，做好準備，設計的更合理些
3、 第三次作業
3.1 需求分析
本次作業，需要完成的任務爲包含簡單冪函數和簡單正餘弦函數的導函數的求解。
運算法則包含加法和乘法，因子包含常數項，變量項和三角函數項，另外定義了更多概念，三角函數也允許使用冪函數了，三角函數裏面嵌套的內容範圍得到了極大的擴展，導致正則表達式基本無法直接應用。本次作業如何處理輸入成爲了一個關鍵點，其難度我個人認爲不亞於甚至大於設計遞歸嵌套本身。這次作業我得到了很大的教訓，甚至扭轉了我好多不良習慣。雖然付出了很多結果不太好，但還是很感謝這次作業。我趕緊進入正題。具體個人此次經歷見最後的總結。
3.2 實現方案
3.2.1 宏觀架構
這次作業我設計了8個類，分別爲Poly類（表達式類），Term類（項類）和5個因子類（x,sin,cos,括號，number）。看似結構複雜，但這些類之間有着很大的數據和方法共性，我在思考後提取了共性，使用了繼承的技巧。這些類都基於一個基類，這也使得我最後的代碼相對較爲簡潔，雖然有8個類，但最後不記優化部分代碼量不到500行。具體設計見下圖
3.2.2處理細節
1、輸入數據格式化：爲了簡化後續處理，本次作業一開始在簡單判定合法性後就通過特判去除空格和連續重複的加減號了。這也使得我最後遞歸判斷因子合法性時無需再對開頭進行特判（如x因子，++x*3此時x前面兩個加號合法，3*++x此時x前面兩個加號不合法），也無需在子類中過度關注空格合法性這類非本質問題，從而更好地設計類的核心特性。
2、循環判斷，使用堆棧思想提取出作爲區分的加減號或是乘號。（見下圖）
本次作業爲了保證正確性，沒有進行過多優化，但最後還是因爲小疏忽發生了錯誤。
3.3 本次作業暴露的問題
3.3.1 測試問題
本次作業強測弱測都崩盤了。強測80分，互測中5刀，最後發現都是一個同質bug導致的，即在Poly類進行堆棧運算時我誤將開始的部分由0寫爲1，導致處理括號嵌套的時候出現了問題。處理((((x))))這類的測試點沒有問題，處理(((sin(x)+cos(x))))這類數據點則出現錯誤。而我這次測試時沒有使用測試機，而是自己隨手測了些數據，雖然也有括號嵌套的數據，但大多數較爲簡單並未涉及到bug發生處，導致最後釀成大禍。這次作業也提醒了我，必須得使用對拍器等自動化評測工具，避免出現這類問題，畢竟很多時候人自己測試往往會缺失隨機性，很難設計出真正觸及數據盲區的地方。
3.3.2 結構問題
這次作業的難度算是這一單元最高的了，不過經過前兩次的作業鍛鍊之後我已經能夠較好的處理這次作業了。本次作業我自認爲設計的結構邏輯清晰，便於理解，架構挺漂亮的。具體實現細節也許有所欠缺，但整體設計方面問題不大。
3.4 本次作業的UML圖和相關參數
UML圖
參數分析
類
方法
二、查找別人bug策略分析
三次策略我採用的都是如下策略：
1、手動通過枚舉設計WF類型數據
2、使用評測機隨機生成正確格式的數據，檢測計算錯誤
下面對1、2步進行具體分析
對於1來說，我在readme上列出了常見的由空格、多餘正負號引起的WF數據各兩個（如++++x，s i n ( x )等），然後列出了一些項連接及非法字符（\v\r...）導致的WF問題。最後統一進行測試。
對於2來說就是使用編寫的評測機腳本利用xeger模塊生成數據進行檢測。
這種策略效果不錯，在第一次，第二次都A屋的情況下仍然刀了5次左右。
三、第一單元學習整體總結
雖然第三次作業完蛋的一塌糊塗，但這個單元的學習還是讓我很興奮，感覺自己收穫了很多。大一的時候看C++ primer plus的時候也接觸過面向對象這個概念，但那時候因爲自身編程水平較低，不得不過多關注於c++寫class的語法而不是對象概念本身。而大二再接觸面向對象時我的編程技術有了很大的增長，此時語言已不再是我的障礙，我可以更好地關注於面向思想本身。事實也的確如此。這三次作業其實並不是很難，但我依然得到了很大的提高。我學會了如何把握對象的數據和方法共性，並將共同點聚合成類。而且強測加互測這個制度也教會了我很多，讓我開始反思自己的編程習慣。
從大一開始我就養成了這樣一個不好的習慣：做完算法題直接交給評測機評測，評測機說有問題我就繼續改，評測機說沒有問題我就學習其他事情去了。事實上這個習慣是個很不好的習慣，畢竟評測機也不代表一定正確，而且實際工程中很多時候並沒有評測機幫我們檢驗設計的產品效果。我們需要自己對程序進行仔細檢查和雕琢才能設計出真正沒有漏洞的程序。
第三次作業出結果後我有點難受，但不是因爲分數，而是因爲一種莫名的遺憾。第三次我真感覺自己設計的挺漂亮的，設計架構鮮明，類之間共性提取的也較好，具體實現事後聽昂神宣講發現有的地方還是不太嚴謹，但整體挺漂亮的。然後因爲小疏忽導致程序出現了大bug，之前的設計全部成了水中月鏡中花。畢竟代碼美觀整潔很重要，但歸根結底一切的前提還是程序正確性本身。
我以後會加大自測強度，改變自己的設計習慣，塌下心來仔細雕琢自己的程序，力爭不讓這樣的遺憾再次出現。
另外最近學習操作系統，看學校發的小型操作系統源碼時候對一些c語法的使用產生了疑惑（比如說用雙指針而不是單指針設計鏈表），不明白爲何選擇使用這種技巧實現而不是使用更常見的實現方式。上網查了查，偶然間看到了Linus老爺子對程序員的一些觀點，然後恍然大悟。設計程序絕不是一個簡單的機械工作，我現在感覺有時候設計程序就像是在實現藝術。希望自己以後能不斷加深對程序設計的認識，加大對自己的要求，設計出思路更清晰，風格更簡潔，功能更強大的程序。
附：
本次本人檢查程序使用的插件爲UML SUPPORT和MetricsReloaded，相關使用說明可以看pxc學長的博客：https://www.cnblogs.com/panxuchen/p/8689287.html
另外在看到pxc學長博客前我曾考慮用CK度量組對程序進行度量判斷，這裏需要用到的軟件爲sourcemonitor，使用鏈接一併附上：https://blog.csdn.net/yf210yf/article/details/17535713
原文出處：https://www.cnblogs.com/super-dmz/p/10585804.html