當我滿懷期待叩開OO的大門,卻發現寶藏藏在層層阻難以後正則表達式
第一次做業算法
一、度量分析編程
>關於第一次做業的metrics圖分析沒有出現標紅的McCabe Cyclomatic Complexity或者Nested Block Depth,但筆者在第一次做業後也反思了本身的問題:在解析多項式將其中的數據取出時並無設計一個很好的方法,而是繁瑣的if-else判斷和while語句,代碼的嵌套現象仍是比較嚴重的。數組
二、類圖學習
>第一次做業剛剛學習JAVA,對於類與對象的概念還不是特別清晰。因此很容易看到筆者只分了兩個類,並且在方法的分配上並無作的很平均,在ComputePoly類中仍是進行的太多的操做致使此類太過於冗雜。但好在第一次設計我便將計算等部分功能放在了Poly類中,也算是分擔了一部分的職能。測試
三、關於BUG優化
OO的第一次做業,也是筆者第一次去編寫一個完整的JAVA程序。因爲要從長期的C語言的懷抱中掙脫出來,因此教程也要求咱們在寫JAVA面向對象編程的同時寫一份C語言的面向過程式代碼,在對比中去深刻感覺和理解面向對象的思想。此次做業是多項式的加減法,總得來講設計難度不大,但須要注意的細節不少。我分別被公測和測試者各找到一個bug,公測的bug是當某指數在多項式曾出現過且在計算過程當中係數和爲0時,筆者的程序將本不應輸出的係數爲0項輸出了出來。其中的關鍵就在於筆者將數組中的值初始化爲10000,致使在出現這種狀況時反而知足了輸出的條件,使這種特殊狀況發生了錯誤。但追其根本,還是程序先後設計不夠統一完備,而這種特殊狀況的錯誤就是程序矛盾性最好的體現。而做爲被測試者此次互測被測出來的bug則是正則表達式的問題。確實在此次做業當中正則表達式的編寫是一塊重要而又繁雜的部分,爲了不表達式太過冗長並且防止爆棧,筆者已經將格式匹配的正則表達式用split分爲兩部分,但仍是被測試者找到了一個表達式中符號位置錯誤而不報錯的bug。自覺得在測試格式方面做足了準備的筆者沒想到本身的正則表達式仍然存在漏洞,不由感嘆本身離真正的嚴謹還差的很遠。
而做爲測試者,第一次筆者拿到的程序公測就Wrong了不少,待我把他所錯的公測樣例一一看過以後難免爲此人感到一絲惋惜:基本功能徹底沒有問題,但細節與特殊狀況的處理上稍差一些,因而筆者將測試的重心放到了他的正則表達式與對於特殊狀況的處理上。在仔細分析他的正則表達式和一些特殊處理,以及剔除他公測已經錯誤的bug分支以後,筆者仍然發現了他在正則中並無卡多項式的個數以及單個多項式中的項數,並且沒有對於0多項式的特殊輸出0,並且沒有處理過的單純輸出{}。這就是第一次做業中筆者與bug的恩怨情仇。spa
第二次做業debug
一、度量分析設計
>不一樣於第一次做業,當來到傻瓜電梯的時候McCabe Cyclomatic Complexity和Nested Block Depth出現的標紅的狀況。McCabe Cyclomatic Complexity 表示圈複雜度,因爲剛剛開始作項目因此在爲各個類分配職能的時候並無作到很均勻,致使Schedule類中承擔的職能太過於多,致使圈複雜度出現了超標的現象。而Nested Block Depth表示嵌套塊深度,主要表示了if-else語句等循環嵌套現象的存在狀況。而筆者對於輸入的處理仍然沿用了第一次做業暴力的判斷與解析方法,致使嵌套現象嚴重。
二、類圖
>因爲筆者遵循了上課老師PPT以及指導書中的建議,因此此次的類圖調用關係仍是至關清晰與明確。但同時也能看出來在Scheduler類中並無去分不少的方法,而把許多不一樣的操做強行放到了scheduler方法中,致使了上面metrics分析出現的問題。另一個問題就是程序的複用性仍是太多,不少相同的代碼沒有很好的去進行分類以及封裝,這方面的不足我相信也會經過不斷的努力去彌補作的更好。
三、關於BUG
不管是相比於第一次做業狀況繁雜仍是第三次的捎帶電梯,第二次傻瓜電梯的調度問題我的覺的彷佛簡單了很多。因爲只是單純的一條條執行請求,因此也不存在繁瑣的請求關係。固然筆者的第二次做業在公測或互測中也沒有被發現bug的存在,同時筆者拿到的代碼也是至關完美,沒有一點紕漏。因爲此代碼功能簡單也不存在任何問題,故原本準備了雖爲數很少但足夠完備的測試樣例想要在代碼的邊界狀況等方面作些文章,缺被「千山萬水老是綠」的AC而折服。
第三次做業
一、度量分析
>由上圖能夠發現第三次做業的狀況和第二次做業的狀況幾乎徹底相同。這是由於筆者的scheduler_ALS大部分是與上一次做業的scheduler同樣,而且又加入了對於捎帶處理的操做。致使嵌套程度原本就很高的程序顯的過於臃腫(時間有限,沒有充足改善),而圈複雜度也沒有絲毫的下降。又這幾回做業的metrics分析能夠深入地告訴咱們程序封裝以及簡潔的重要性,像筆者前幾回的代碼並無很好的作到這一點,因此在未來的做業中但願能夠有所改進。
二、類圖
>第三次的做業根據要求使用繼承和接口來更好的控制elevator,其餘類並無實質上的改變,都只是小的修修補補。此次做業雖然在處理同質、輸出、toString等方面作了一些封裝的嘗試,但程序上述的問題仍然存在。但總體思路仍是比較清楚的 -_- 。
三、關於BUG
在通過平淡的傻瓜電梯以後,電梯的捎帶問題又掀起了一陣波瀾。此次做業投入的時間與精力也是最長的,筆者也給本身作了許多的測試。但反映出一個重要的問題就是因爲難度的上升筆者將測試的重點徹底放在了測試捎帶這個功能上,從bug樹中每一種狀況,到多個100行的測試完備功能的代碼,再到3w,5w的超強測試樣例,在一次次修正與補丁之後程序的功能終於完善了。但我卻忽略了一個致命的問題,對於不符合規範輸入的請求的輸出格式錯誤,而愚蠢的筆者居然沒有去進行測試致使公測的錯誤,總有種撿了芝麻丟了西瓜的愧疚心理。固然吸收經驗,避免遺漏基礎與細節也是至關重要的。並且在後來的自我反思中筆者發現了另外一個小bug,就是當處理STILL類的請求時判斷同質遍歷的初始變量是0,也就是從第二個STILL開始程序會將請求自己也當作同質請求。雖然僥倖沒有被測試同窗找出這個小bug,但筆者的心裏仍是有點後怕的。-_- 而此次筆者拿到的代碼做業與第二次做業同樣優秀,筆者徹底按照給本身代碼測試的方法,從一條條bug樹類樣例到超長的功能測試代碼都沒有找到這份做業的錯誤。打開代碼分析其正則以及各種輸出的格式方面也一無所得。致此,第三次做業的bug之旅也就到此結束了。
心得體會
1.剛剛步入JAVA和麪向對象的世界,雖然也見識過不少dalao對於代碼的精緻封裝,但真要本身在有限的時間內既要完成代碼又要有良好的設計着實對於我這隻小caiji來講還有點困難。到仍然要去不斷進步地去劃分每次做業中的類,運用好封裝相當重要。
2.我在完成此三次做業的時候就已經想到應該先將整個程序的思路徹底想清楚並大體給本身畫一張相似於類圖的設計思路,儘可能細緻,清楚。這樣會大大減小在以後開始寫代碼和debug的時間。但我可能作的還不夠,尤爲是第三次做業,在寫完以後bug仍像浪潮通常一波又一波侵襲着我。
3.關於調試與debug,我的認爲雖然JAVA中單步調試很方便也很簡單,但有時單步調試並不能真正反映一些代碼的細節與內涵問題。因此在不少狀況下print式debug大法仍是頗有必要和實用性的。我建議二者要結合起來靈活使用,可能涉及到更加細微的地方使用print更能說明問題。但無論怎樣,不管用什麼方法,快速而準確地找出bug且明白錯因纔是最重要的也是最終的目的。
4.關於時間的分配與利用上,筆者有作的好的方面固然也有作的不好的一面。每次週五就已經佈置的做業筆者都拖到週一去開始動工,雖然啓動晚可以看到更加完善合理的指導書與issue,但總體進度的拖沓仍是致使了熬夜的出現。而我的認爲比較好的一點是筆者在開始項目的時候去把全部的工做作了詳細的時間規劃與進度要求。好比思考並畫出思路圖的時間能夠說應該是整個做業過程當中最長的,其次是寫完程序後的debug和測試的時間,真正完成主要代碼的時間很短,而這也正符合了思路清晰完成較快的一向原則。隨着做業難度的不斷增大與深刻,在從此幾回做業筆者吸收熬夜的教訓,儘早去動工着手做業。
5.筆者認爲前三次做業不但將咱們從面向過程式的編程拉到面向對象上,一樣教會了咱們處理細節問題的重要性。其實在互測過程當中不管是筆者本人仍是其餘不少同窗,自身代碼功能考慮的很全面,測試也很完整,但在不少格式方面或者指導書中不起眼的小規範上卻翻了陰溝。這深入地警示着咱們不能只光顧着代碼功能的完善,而是要以更加縝密的思惟去應對一切代碼中可能出現的問題與狀況。而這同時就要作更加完備的計劃與測試,每出現一種新狀況或邊界問題就要加入到本身設計的流程圖中,將問題和本身的代碼和諧地融爲一體,這樣才能更好的避免細微錯誤的出現。
6.Emmm 最後就談談互測吧,畢竟有很多人從第一次做業開始就吐槽OO的評測體系,筆者這裏僅僅發表一些我的見解。筆者倒認爲互測實際上是一種很培養你們讀代碼以及測試能力的。爲了寫出他人便於閱讀的代碼,咱們不斷的在完善本身的編程習慣好比寫儘可能詳細的註釋,將代碼分裝到清晰明瞭。同時你們也能夠從分配到的代碼中學習到不少的東西,好比規範的編程風格與更加優化的算法等,相信OO互測自己的意義也體如今這裏。因此筆者在這裏想告訴你們的是咱們能不能將關注點更多的放在雙方代碼優秀與否和互相學習切磋上面,而不是有一種「爾虞我詐」的既視感。
寫在最後
~~總而言之,從剛開始對面向對象這個概念都懵懵懂懂,到如今三次做業後的略知一二,通過了幾個午夜的洗禮,你們也算是逐漸正式步入了OO的你們庭中。在此感謝在完成過程當中幫助過個人同窗以及在互測過程當中對我程序認真負責的測試同窗。但願咱們可以正視這門課程的真正意義所在,共同努力共同窗習共同進步,借鑑彼此。最後祝你們JAVA越學越6,代碼越寫越美,OO越肝越牛逼。