前言
這兩次大作業使用到的新知識點並不是很多，考查的是各類知識點的綜合應用，題量方面大概考慮到這兩次大作業的難度和臨近考試的學習壓力，兩次大作業都只有一道大題，由於是所有知識點的總結，考察的知識點很廣，再加上迭代的次數增加，這兩次大作業的難度比之前的幾次都要提升了不知一個檔次。第七次大作業中的單刀雙置開關增加了對於單刀雙置開關所在的串聯線路的資訊獲取與處理儲存的需求，同時增加對於單刀雙置開關切換狀態的處理的需求，再加上對於多並聯以及串聯中含串聯的情況考慮，使得第七次大作業需要考慮的東西增加了非常多，同時也使得程式碼必定會比之前兩次迭代複雜很多。而第八次大作業新增的二極體以及對於所有用電元件引腳兩端的電壓都列舉出來，使得之前三次迭代一直在使用的分壓計演算法以及判斷電路是否短路的方法都全部被推倒，被迫透過考慮電流這一物理量來計算各引腳上的電壓以及用電器的輸出量，所以第八次大作業基本就宣判讓我重寫了，導致此次大作業的難度上市了一大步。
設計與分析
從這就可以看出我第七次大作業完成的非常困難了，光從圖就能看出程式碼非常複雜，而將它完成的過程就更復雜了。不過我不得不承認，這樣的類設計不但不是最好的反而是非常差的，起碼在我所瞭解過的同學的類設計中，我這個算比較複雜的，其主要原因還是上一次大作業設計類時的思路就是這樣，對於上一次大作業這樣的類設計與資料計算思路雖然實現起來不會很簡單，但不至於難的很離譜，而這次迭代在在整體框架上並沒有改動很多，所以就直接繼承上一次大作業的設計思路來設計了，但很顯然，同樣的設計思路在不同的需求數量下的複雜程度完全不是一個等級的。
這是上一次大作業的設計，可以看到，我上次大作業的設計思路對編碼就不是很友好，並且我沒有建立控制元件與用電器作為父類，所以讓類的關係光看起來都非常雜亂無章，我完成上次大作業所用的大部分時間就基本都在梳理和修改不同控制元件與用電器的關係與各自的呼叫方法上了。而這次大作業更加複雜的類的關係與各種相互呼叫就讓這個梳理過程更加漫長與痛苦了。相較於上一次大作業，這次大作業在類設計上的改動主要為新增的單刀雙置開關類，這個類主要是用來儲存處理與之相關的兩條串聯支路的斷開與連線狀態。可能這麼說會顯得這個功能很容易實現，但實際情況是這個類如何與line類相聯絡以及兩個不同引腳的轉換還要牽動電阻的轉變這幾點讓我麻煩了很久。
難以啟齒的是，第八次大作業我並沒有完成，正如前言中所述，我完全從零開始改編了我的思路，從考慮電流的方面重寫了所有的程式碼，但很可惜我並沒有做到完全用新的方法解決最後一次迭代這個難度的編碼，不過主體思路還是有的。我的想法是在處理串聯支線時將讀取到vcc以及gnd的那條主線路的總電阻求出，再以此求出幹路的電流，而並聯支路的的電流則用幹路的電流依據支路電阻的反比來求，而電路元件的前引腳電壓與前一個用電器的後引腳電壓相同，後引腳電壓用前引腳電壓與透過電流與電阻乘積求得的元件電勢差相減得到。但是在實際實現的過程中，短路的情況，單刀雙置開關的情況以及各種控制元件對於電路狀況的影響使得我一直難以在短時間內實現這個想法。
踩坑心得
在第七次大作業中，因為沒認真看題目吃了一個很大的虧，因為習慣性地根據測試樣例來判斷輸出條件，導致在單刀雙置開關接引腳三時，顯示單刀雙置開關的狀態也一直是閉合，就單這一點就讓我浪費了很多時間，甚至發現這個錯誤都不是我重新讀題發現的，而是同學提醒的。
然後很重要的一點就是方法的考慮了，前三次迭代一直使用的是分壓法求用電器的電勢差，而第四次迭代新增的要求幾乎直接ban了這個方法，因為之前沒考慮到這種情況，而選擇了分壓法這個明顯簡單很多的方法，所以第四次迭代完全沒法順接前三次的方法。
其次是未考慮到並聯電路全斷的情況，導致即使並聯部分是斷路，幹路部分還是有電壓，用電器也能正常輸出，找到這個錯誤還是我不信邪用筆畫出電路自己計算與程式輸出進行對比時偶然發現的，如果不是運氣好可能我還一直不會考慮到這個情況。
還犯過的一個比較大的錯誤是帶有單刀雙置開關的並聯線路的電阻計算錯誤，因為單刀雙置開關的電阻我是作為單刀雙置開關自己的屬性儲存的，導致在計算並聯支路的總電阻時沒有加上單刀雙置開關的那部分電阻，進一步導致了用分壓計算各用電器的電勢差時全部出現了錯誤，不過這個錯誤在我發現多組測試資料都對不上正確輸出時就發現並改正了，所以並沒有造成太大的困擾。
改進建議
對於這兩次大作業的程式碼方面的改進建議我認為主要有以下幾點：
- 對於同一個資料儘量只進行一次儲存（只儲存在一個類中），防止出現多處儲存的資料在更改時沒有同步進行更改，導致之後的計算出現錯誤。
- 儘可能降低類與類之間的耦合度，特別是兩個類之間同時存在多次呼叫對方的情況，降低可能因此出現的邏輯混亂進而導致出現錯誤的可能性。同時還需要降低類之間關聯關係的出現。
- 對於重複出現的方法可以考慮寫一個複用性強的總方法來實現，透過呼叫該總方法減少程式碼量，降低程式碼的重複率。
- 對程式碼進行分塊化處理，將不同功能的模組區分開來，單獨執行相同或相似的功能，以減少排查錯誤的難度以及增強程式碼的可修改性，同時在不同模組前使用註釋標註好各模組的功能，以方便更容易地找到需要排查或修改的程式碼塊。
總結
這兩次大作業說實話對我有一定的打擊，畢竟這兩次大作業確實完成的非常差，也讓我再次意識到了自己的幾點不足：
- 讀題還是不夠耐心，且過於依靠測試樣例，在完成大作業時總是急於寫程式碼，導致經常看漏或者忽略很多關鍵的資訊，這一點也在這兩次大作業中體現的非常明顯。以及在這麼多次大作業中可以明顯感受到自己過於依賴測試樣例，以至於經常出現測試樣例全部透過但是分數卻非常低並且要花很長時間才能找到一個錯誤的情況。
- 考慮問題不夠全面，每一次迭代時都只考慮了此次迭代的情況，沒有為之後的迭代做好鋪墊，導致每一次新的迭代難度都會呈指數級上升，甚至會像這次一樣連從上一次迭代進行修改的可能性都沒有。
- 程式碼的可讀性不高，對於變數的命名沒有規律和標準，經常在使用時混淆不同的變數，同時程式碼重複性太高，導致排查修改程式碼時經常需要從極度相似的程式碼中尋找需要尋找的程式碼，並且對於程式碼的標註過於隨意和稀少，經常連標註都看不懂或者搞錯。
- 程式碼過於雜亂，雜糅，經常許多不相關的程式碼混雜在一起，即使進行標註也很難理清楚某塊程式碼具體有多少，有哪些作用，在修改時也經常修改到一些不改動的程式碼，導致改錯反而變成了加錯。
在完成了這麼多次大作業後，我也清晰感受到了自己不斷成長的過程，也證明了不斷練習確實有很大的作用，也意識到了自己的不足，而在今後的學習中，我也會結合自身的不足進行針對性的強化學習，希望自己能在今後的學習中更進一步！
建議及意見
對於本學期該門課程的學習，整體來說還是很滿意且很有收穫的，但在一些方面我還是有一些建議：首先是課堂上對於知識點的講解我還是更習慣用具體的程式碼示例進行演示講解，並及時給出相應的練習，在剛接受完知識點能儘快的自己使用，深刻地去了解。其次是對於大作業，可以多向後面幾次大作業那樣在釋出後幾天讓完成得比較順利，比較快，比較好的同學分享他的思路以及他讓為比較關鍵或者易錯的點，讓我們擁有更多想法及可慮方向。