第二次博客做業

第五次做業

1.度量分析

 

 

因爲電梯線程須要控制本身的運行，關於運行的判斷過多，if嵌套過多,if用的也太多，致使Nested Block Depth和McCabe Cyclomatic Complexity標紅。

2.類圖

 

 

enter線程負責輸入，調度線程（sche）負責調度電梯請求，根據規則分配給各個電梯，而電梯線程（lifts）負責執行本身所分配到的請求，掌管本身的運動。其他的是一些請求類，請求隊列，電梯類等等直接繼承上次做業的。

3.關於bug

此次做業因爲粗心，沒有及時將電梯運動量傳至調度線程，致使公測那個點掛了。而筆者負責測試的程序並無發現bug。

第六次做業

1.度量分析

 

 

因爲筆者的監控線程，用了過多的if語句嵌套，致使Nested Block Depth和McCabe Cyclomatic Complexity標紅，此外筆者的監控線程負責整個監控器的運行，因此將太多功能賦予它了，整個類顯得冗餘複雜。

2.類圖

 

 

監控線程（monitor）負責了太多功能，基本監控線程全部的運行方式都在monitor類中實現，致使整個類看起來至關冗餘，且難看。

3.關於bug

因爲以前覺得Modified只是最後修改時間發生改變，但筆者覺得若是最後修改時間和大小都發生了改變就不是Modified，而是size-changed，最終致使Modified樹被報錯，且Modified關於這部分測試也被測試者掛滿了bug，實在是很惋惜。此外筆者的編碼格式忘記修改，不是UTF-8也被報了個incomplete，並且非法請求會佔用筆者的10個線程中的名額也被報了incomplete，總之此次做業讓筆者深入認識到了細心的重要性。而筆者測試的程序此次也沒有發現bug。

第七次做業

1.度量分析

 

 

筆者的taxi線程掌管其全部運行，致使這部分的代碼過長，判斷運行方向過多，最終致使McCabe Cyclomatic Complexity標紅，此外調度線程（sche）的判斷嵌套過多，致使Nested Block Depth標紅。

2.類圖

 

 

主要有出租車線程(taxi)以及調度線程(sche)，請求類(Request)和尋找最短路徑類(即bfs類)。

3.關於bug

此次因爲在乘客請求無車響應時，沒有通知乘客，而被報了個bug，此外因爲筆者的請求紅框在GUI只會顯示最後一個，這讓筆者的測試者感到困惑。而筆者測試的程序此次感受水平明顯降低，公測中明顯（80，80）已經超出地圖範圍卻會繼續執行，最後致使程序crash。此外程序的運行也莫名其妙。

心得體會

筆者認爲多線程中相當重要的即是線程安全，若是不對線程加以控制，每每會出現不少莫名其妙的錯誤，這是因爲線程競爭的不肯定性，在第一次多線程時筆者覺得加了synchronized 便能解決這個問題，如今筆者才發現線程安全更依賴於一個好的架構，不是全部的共享資源都須要加鎖，另外也須要注意死鎖的問題。此外筆者發現一個好的寫代碼風格可以極大的減小bug的出現率，另外調試bug時因爲本身程序的簡潔性可以一目瞭然哪裏出現了問題。把每一個類的功能具體化，分類化，這樣出現bug也能很快知道哪裏出現了問題。