buaaoo_fourth_assignment
你輕輕地走了
一、架構設計
（1）第一次作業
類圖
復雜度分析
如上圖是本單元第一次作業的架構設計，由于本人最開始未發現可以直接繼承官方的類，所以自己將所用到的各種type都重新建了類，于是這就導致了整個src里面看起來十分臃腫。不過這樣做的好處是完全理解自己的類中應該放什么，不應該放什么。并且大部分類都是比較重復的存取id和name，操作比較簡單，所以寫起來的感覺還不是很壞。
我覺得在本次作業中，比較難寫出來或者比較容易錯的方法都是需要統計包含自己父類中的操作或者屬性的方法。這樣就要求在書寫程序的時候使用遞歸或者dfs、bfs等算法，來尋求到父類中所存的屬性等。由于我將各個類的屬性與操作等全部存到了Umlclass類中，所以之需要按部就班的跑一個dfs就可以統計到它對應的所有父類中的屬性或操作。
這里有一個比較煩的點就是，接口是可以多繼承的，所以在實現的時候需要對dfs進行遍歷，增加了程序的復雜度，甚至還一度擔心可能會超時。
總之本次作業第一次寫完之后，就幾乎沒有bug，只是有一個方法理解錯了，不過好在有對拍的存在，然后找到了就直接改了，所以十分的穩。在架構上覺得已經初步理解了面向對象的思想，比較好的進行了類與類的解耦。
? （2）第二次作業
類圖
復雜度分析
以上是第二次作業的類圖即復雜度。
從上面可以直觀的看出，我建了25個類，這也是由于沒有繼承官方類的緣故。而且我不得不將對UML類圖分析與順序圖和狀態圖分開，不然單個類的代碼行數就會超過限制，而反觀我的朋友卻沒有這樣的問題，可以看出我在架構設計上還不是很熟練，我認為的問題有，為減少方法行數而將一個方法可以實現的功能拆解到好幾個中，而且由于沒有繼承官方類，冗余重復的方法比較多，所以導致了src的類有25個，顯得十分臃腫，如果之后還要做有這樣需求需要仔細研究一下官方類之后再去設計自己的架構，不然就會越寫類越多。
從本次指導書中分析，可以說涉及到順序圖和狀態圖的部分已經被課程組大大的簡化了，估計是考慮到同學們的烤漆時間不太充足，里面涉及到的六個方法，只要理解正確統計的是哪個type，就只是數數而已，可以說是十分良心的作業了。但是由于數據限制的問題，我也想了很久才去寫，如果沒有那些數據限制，實際上還有很多的細節需要去考慮，這里就留給優秀的窩窩助教，對下一屆進行慘無人道的鞭撻吧。
至于對于類圖的檢查部分，這里確實是十分容易出現bug的，R001還比較容易，R002繼承循環就有比較大的問題，最開始是考慮跑dfs，直接記錄路過的路徑，然后直接得到一圈數據，后來經過朋友提醒，可以用for循環，一次只得到一個數據，這樣做雖然復雜度上升了，但是比較好寫。同理，對于類也是這樣，只不過在處理的時候，由于多繼承的存在，復雜度再次上升，好在數據不是那么強，所以才得以幸存。
我覺得最難的就是R003的檢測，額，也不能說是難，就是想比較簡潔的寫出來，復雜度爆高（指循環dfs找類，在每一個類實現的接口進行dfs找其繼承的接口，看訪問次數，如果大于等于2那就說明重復繼承了），其它的倒是還好，看了一下強測跑的秒數，最慢的1.3s，最快的也1s，和朋友一比稍顯遜色。這就說明自己設計的方法只是求寫起來比較簡易，而沒有考慮性能的問題（還好沒有性能分）。
（3）總結
總的來說，這兩次作業雖然都和烤漆離得比較近，而且寫起來也比較費時間，但是都滿分還是比較不錯的回報，這兩次的架構是真切的體會到了面向對象進行解耦的好處。因為我兩次作業都和朋友去對拍，然后發現了bug之后，覺得十分好改，而且改了之后完全不擔心其它的功能會因此出錯，因為兩者完全不相關，所以說，至此可能面向對象才算入門吧，這單元也是我歷次作業中覺得自己架構設計的最好的一次，終于由完全的面向過程，轉向了面向對象。
二、架構設計及OO方法理解的演進
（1）第一單元
這個單元是剛開始寫java代碼，上來就是十分難受的字符串處理，而且還加入了wf的問題，我覺得這點對OO新手來說不是很友好，尤其是第三次作業，嵌套求導讓我這個面向過程選手直接推倒，完全重寫，花費了十個小時之多，不過好在沒有出現bug，不然就虧大發了。
因為那時候剛剛接觸面向對象，本著偷懶的原則，沒有細細去理解，于是寫的就完全是面向過程，一兩個類打天下，過后再回去看自己的代碼真的是慘不忍睹。如果稍微改一下需求就需要完全推導重來。
如果當時就理解了面向對象的思維的話，或許我會分解成x類，sin類，cos類等，進行解耦，來獲得更好的順延作業體驗。
我印象最深的就是，把功能完全實現了之后，瘋狂拆自己代碼中的方法，看哪里能拆，就分出另一個方法，不然就會出現checkstyle問題，這更可以說明自己當時的碼力十分的弱。
（2）第二單元
這個單元是多線程，感覺也是理解起來比較費解的一個部分，因為輸出是不確定順序的，有的時候bug完全無法定位，不過好在實現了代碼之后就沒發現bug，不然寫起來真的是惡心。
可能是由于要訓練多線程，而且考慮到大家剛接觸，電梯的要求其實還不算困難，只需要很少的代碼就可以實現。
我也是在這時候才體會到，不需要完全推到重來的代碼有多么舒服。第二次的電梯可以經過少量的修改直接應用到第三次中，這里就運用到了解耦的思維，只需要把控制器調度的代碼進行少量的修改，就可以實現所要求的功能，而且性能也不算很差。本單元可以說是我寫的最舒服的一次作業，總用時也最少，加在一起的時間甚至還沒有其它單元最后一次作業用的時間多。
（3）第三單元
這個單元是對于圖的理解（數據結構還債課）
為了完成本單元最后一次作業，我成功的自學了dfs，bfs，floyd，dijkstra等一系列圖的算法，這在當時的DS中都是直接抄PPT模板就完事了。
最難的是第三次作業，前兩次并沒有什么難度，最開始的時候，確實不清楚應該如何去實現最少票價和最少不滿意度，看了討論區大佬的帖子之后才知道只需要把權重矩陣修改，把連接修改，就可以通過bfs來得到了票價和路徑，可由于用floyd是一次性更新整個圖，而我當時架構設計必須使用floyd，經過計算，復雜度絕對會導致自己超時，想了很久不知道應該怎么辦，還是經人提醒，才明白加入一個cache就可以了，把之前更新過的矩陣存起來就行。這可以看出我對于代碼的思維能力還有些欠缺，在其它地方學到的知識無法很好的融會貫通。
不過這次的架構 也還可以，修改也比較容易，我重構了第三次作業三次，這點十分不友好，十分爆肝。
（4）第四單元
具體分析在之前的一中已經分析過了，這里不再贅述
（5）演進總結
可以說從第一次的表達式求導中的純面向過程，逐漸轉向了面向對象，這經歷了一整個學期，速度不是很快，但好在最后還是稍稍理解了面向對象究竟是怎么一回事，也算自己沒有白上這個課。
我深刻的體會到了OO的方式寫代碼，在發現自己bug時，可以十分容易的就去修改。而之前和別人對拍過的不出錯的功能可以不用再重復檢測，之需要面出現bug的部分修改就可以了。而面向過程如果需要去修改bug，甚至可能把整個代碼推倒重來。這四個單元確實讓我對面向對象思路從最開始的抗拒，到逐漸接受，再到現在覺得這簡直是精品。
變化還是很大的，希望自己可以把面向對象的思路應用到以后的寫代碼中吧。
還有一點值得注意的就是對于變量的命名問題，由于第四單元最后一次作業我涉及的類比較多，所以對于變量的命名十分具有迷惑性，我在改bug的時候差點就迷惑了，就得先看代碼才能知道當前變量是做什么用的，這點是在架構設計中做的不太好的地方，之后要改進。
三、測試的演進
首先我覺得課程組所講的各種測試方法，比如從最基礎的讀代碼找bug，應用看嵌套之類的技巧，到用junit生成測試樣例進行半自動化測試，都是十分不錯的測試代碼功能正確性的方法。不過在我們課程這樣密集的作業和debug和互測節奏中，這樣并不是很快速的測試方法并不是很友好，可能你在電腦屏幕前盯了一天，修改了很久junit，只找出了幾個甚至一個bug，這對于自己時間的浪費與得分的比值是十分不值得的，如果唯分數論的話，這樣的測試比較拖慢節奏。不過我相信，課程組所教的方法都是以后在工作過程中真正要應用的方法。我本人每次測試都是使用了對拍，和同學的程序，或者自己寫的python程序去對拍，以此來發現自己的bug，或者是互測找別人的bug，掛幾個小時就可以收獲好幾個bug，在時間效率上還是很不錯的，雖然這樣失去了認真發現別人bug的機會，但是在閑暇時刻，讀讀架構比較好的大佬的代碼，也是可以精進自己的思維的。我個人比較推崇針對不同的情況用不同的測試方式，比如說對于這種密集作業型來說，就適合用對拍來解決，所以我也是這樣做的，而對于之后工作上的代碼，并不可能讓別人的程序和自己的功能性做對拍，而且也大多數是交互情況的代碼，十分不容易去寫出對拍，這時候就能應用到課程組推薦的方法了。所以我認為，沒有最好的方法，只有最適合的方法。
四、課程的收獲
我覺得課程給我最大的收獲是如何寫出優美的對拍程序（誤）
之前也分析過了，從面向過程的C編程法，到現在的面向對象的java編程法，我覺得自己編程的思路上面有了很大的拓展。而且之前寫的程序代碼行數都比較短，以至于寫出第一單元的作業的時候還驚嘆了下，作業代碼行數怎么這么多，好幾百行，后來就逐漸習慣了越來越多的代碼行數，越來越大的壓力。可以說這個課程帶給我的不光是編程思維的改變，還有對于壓力的抗受能力，從最開始寫幾百行就覺得十分疲憊，到現在連續寫一兩千行也覺得是灑灑水，我想這確實可以表現我的蛻變。
回顧一下各個單元，第一單元的時候，剛開始學習寫java代碼，只經歷了寒假作業比較簡單的培訓，就直接去寫幾百行的大程序，最開始確實有些吃不消，當時還在和馮如杯做斗爭，所以還有挺大怨言的。寫第三次作業的時候差點自閉，因為那周周六得去答辯，得從周日開始寫，最開始還沒什么思路，不過好在都過去了。
之后到了多線程，因為上課時候只是從理論上知道了多線程的相關知識，但是沒有從實踐上真的去寫還是不行，引用之前數據結構老師的一句話“learning by doing”，對于編程這一課，確實不能只停留在理論上，而更應該動手去做。第二單元的第一次作業還摸了魚，并沒有用多線程去寫，然后第二次作業成功還債。不過由于為了讓我們體會多線程而降低了難度，還是比較容易完成的一個單元。
在之后就是數據結構和圖論還債課，正好是這個單元剛開始，家里出了點事情，心態完全爆炸，于是每次就等著問別人的思路，然后草草寫完，再寫個對拍就不管了，所以這個單元感覺做的比較失敗，雖然全部正確，但是對這個單元的印象最淺，感覺并沒有學到什么東西，只是把以前的東西進行了復習。
最后一個單元的作業和烤漆糾纏在一起，不過好在課程組幫我們進行了延期，不然我甚至可能都不會去寫本單元的最后一次作業了。在考馬原的前一天，和朋友進行了對拍，找到了自己的一個bug，不過后來發現是因為課程組限定了不會出現那種情況，而我朋友的代碼處理了，我的沒處理，無傷大雅。
這一個學期下來，收獲了很多，有過開心，也有過痛苦，不過總歸是還算圓滿的完成了自己的工作，也希望OO課程可以越辦越好吧。
五、建議
詢問過學長之后，發現今年的OO課程進行的改進十分的巨大，其中比較好的部分就是，在互刀的狼人階段，不用完全靠助教仲裁，而是采取更科學的評測機方法，讓人信服，觀感很好。
但是，OO經常被掛在知乎上，我覺得也是有原因的，雖然可以說是人無完人，課程組也盡力了，沒有辦法盡善盡美，但是我覺得確實還有一些問題需要提起課程組的注意。
首先是對于延期的問題，第一單元第三次作業，僅僅是因為有很多同學沒寫完就去延期，這完全不符合公平的原則，對于全部正確的同學可能無所謂，但是對于出現了bug的同學，這樣的延期可能導致排名下降，分數下降，我相信課程組是為了大多數人著想，但是反過來想，為什么不能讓不能按時完成任務的人得到應有的懲罰呢？難道以后去工作了，老板會很寬容的原諒你沒有按時完成任務嗎？我覺得對于這種事情，課程組還需要再斟酌斟酌。
其次是對于指導書描述的問題，從第四單元最后一次作業可以看出來，對于數據描述的不清晰，很可能導致同學們無法書寫代碼，因為可能理解不同，就得把代碼整個推倒重寫。當然，課程組肯定無法在發出指導書之前就能考慮到所有的問題，但是我希望在每次指導書發出來之前，課程組可以進行內部討論，看看針對指導書可能出現什么樣的情況，對數據進行規范化，就好像第一單元作業那樣，十分嚴謹的寫出了表達式的定義，這就讓同學們可以更快更好的上手。
最后是希望有可能的話，調整一下作業的順序，或者調整一下作業的結構。就拿本學期的課程來說，沒有學過java的人，上來就開始寫一個大型的表達式求導程序，那估計大部分人都會直接選擇自己更熟悉的面向過程方式，這樣這個單元的作業就失去了對于面向對象訓練的意義，如果在開始的時候，進行類似于完形填空，補全方法一樣的面向對象訓練，在第一單元最后一次作業再讓同學們完全由自己書寫面向對象的代碼，可能會讓同學們更加容易接受面向對象的思想一點。
窩窩課程已經落幕，而我們仍需繼續前進，希望窩窩課程越辦越好，也希望我們越來越好。
?正如你輕輕地來
轉載于:https://www.cnblogs.com/dxy1999/p/11066065.html
與50位技術專家面對面20年技術見證，附贈技術全景圖總結
以上是生活随笔為你收集整理的buaaoo_fourth_assignment的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： C - Line-line Inters
- 下一篇： OpenCV2:幼儿园篇 第一章 创建图