(1)從多線程的協同和步控制方面，分析總結自己三次作業來設計 策略及其變化。

多線程電梯：

由於是第一次接觸多線程，我在還沒有理解概念的情況下貿然上手，導致線程同步非常混亂。現在再來分析，發現思路其實還算清晰。InputHandler與調度器之間是生產者-消費者關系，中間應當有個線程安全類requestTray。調度器和各個電梯的存儲隊列間也是生產者-消費者關系。

IFTTT：

本次作業我認為我在多線程控制方面比電梯好很多，沒有出現線程方面原因造成的bug。重要原因在於本次作業的多線程協同其實只出現在了文件操作方面，說白了是建立snapshot與測試線程修改文件之間的沖突。那麽只需要在建立snapshot時上鎖，同時將測試線程的所有方法上鎖即可。

出租車：

我認為我這次的線程安全反而搞復雜了。InputHandler要讀取電梯的狀態，電梯自身要讀取並修改自身的狀態，請求監控器也要不斷讀取電梯狀態。這樣鎖的切換之間造成的消耗很高，也容易出現bug。

(2) 基於度量來分析自己的程序結構

多線程電梯

可以看到，本次作業的一些主要方法，比如主函數的run，電梯的update，判斷同質請求的函數、進行捎帶分配的函數，這些功能非常重要的函數的圈復雜度依然很高，顯得很臃腫。一部分原因是因為這是電梯系列作業的第三次作業，所以自己一直在不斷地在原用功能上加東西，而此時還並沒有特別能靈活的利用繼承和多態，高內聚低耦合的思想也沒有很好的貫徹。

IFTTT

可見這次作業的各個復雜度均比上次作業好了很多，也分散了很多。原因在於這次作業整體的設計比較明確，每個觸發器有針對的方法來進行判斷。但是缺點在於我把所有的判斷觸發器條件的邏輯都放在了SafeFile類裏，導致該類復雜度非常非常高。對於這點我也沒有想到太好的解決方法。

從類圖也可以看出我這次的設計思路比較清晰，不像電梯那樣不斷往上加東西導致很雜亂無章。在主函數Run中實例化各個觸發器的線程，各個觸發器通過trigger函數輸出信息。SafeFile裏則封裝了相當多的文件檢測方法。

第一次出租車

這次作業由於加上了GUI所以類圖顯得很亂。除去GUI的方法外，復雜度高的方法還是集中在了主要線程的run方法中，比如Taxi和Scheduler。令我驚訝的是InputHandler的類復雜度居然如此的高，查閱代碼後發現是裏面一個checkStatus函數用了連續的if-else和循環結構來檢查100輛出租車的狀態，以此作為測試接口。這也說明了在以後的設計中應當盡量減少多重if-else的邏輯結構以及switch-case結構來降低復雜度。

(3)分析自己程序的bug

第五次作業：

這次作業是第一次接觸多線程，我在沒有完全理解多線程機制的時候就貿然寫完了程序，最後發現會出現線程阻塞，死鎖以及很多無法解釋的線程沖突現象，導致絕大部分有效點都沒過去，不過還是遇到了好心人看出我是線程安全出了問題。。給過了幾個點。。

第六次作業：

由於未被測試，因此不知道有沒有什麽bug

第七次作業：

這次作業最大的問題出在了同步時間上。因為我程序運行消耗時間過慢，雖然我采用了加時間來進行輸出，但是在運行過程中還是會出現一些bug，而且這些bug還是隨機復現的。總共被找出來兩個，一個是接單的時候信用不是最高的車，一個是輸出時間有誤。

(4)分析自己發現別人程序bug所采用的策略

第五次作業未找到bug。第六次作業找到一個文件安全的bug，第七次作業找到兩個出租車時間未同步造成的bug。

使用策略通常取決於被測者的代碼可讀性。。如果命名實在難以理解，我通常就采用按分類樹的黑盒測試以及暴力測試。如果命名較好，我會根據程序進行分析。比如多線程電梯的運動量+捎帶等邊界點，出租車上下車停止時的邊界點等等

(5)心得體會

多線程電梯：

首先，可能是因為第三次作業我的程序沒有bug，導致我誤以為自己能力還不錯，結果就是多線程電梯等到周日才拿出指導書開始讀。對於多線程，我也小看了他的威力，以為其只是類似於正則表達式這樣的工具，從而在多線程方面我在沒有徹底搞懂其原理的情況下就貿然上手編程，也沒有做好完整的設計。最終的結果就是我熬夜寫出了代碼，但是bug卻一塌糊塗，也不知道多線程的交互是哪裏出了問題，debug任務艱巨，最終沒能很好的實現電梯。

經驗教訓：搞懂多線程原理再上手寫代碼，可以自己先寫一些小規模的程序來驗證自己的猜想，否則電梯這樣巨大的代碼量 debug難以駕馭；設計必須先於實現，最好是在稿紙上寫出邏輯的偽代碼，畫出類之間交互的關系圖；最後，不要拖延，早點開始寫，留出足夠的時間。

IFTTT：

我認為本次作業和核心在於“snapshot”的建立。本次作業觸發器的本質是對比兩次監測下文件信息的不同，那麽只需要存儲文件信息的"snapshot"即可。而線程安全問題（訪問沖突）也就在snapshot讀取和測試線程修改之間。只要分析清楚了這個關系，線程安全方面的建立就非常容易。這次我初步體會到了設計的重要性。

第一次出租車：

這次我深深感受到了數據結構和算法底子薄弱的劣勢。。人家寫的bfs瞬間跑完了。。我寫出來的bfs就嚴重影響程序運行，甚至帶來不可避免的bug。下次作業我務必優化算法，減少相關bug。

OO第二次博客總結