OO生存指.....抱歉沒法生存

還記得前三次的設計策略：星期二以前實現功能，星期三找一下可能出現的小bug。

這三次以及變成了：星期二以前能跑出來就行。

整體來講設計策略是：先讓幾個線程可以順利運行，再開始實現功能。

在接觸到多線程以後，我已經沒有前三次做業的餘裕了（雖然前三次也不怎麼有）。

還生存個鬼嘞，不無效就好了吧 = =

---

 第五次做業：多線程電梯（三電梯）

據說是全部做業中最難的一次了，事實上也徹底對得起這個名號。此次做業對設計架構，線程安全的要求都是至關高的。並且對於測試來講，由於三線程電梯的隨機性實在不高，測試時很明確，也提高了此次做業寫出來的難度。比起來以後的出租車隨機性更高一點，固然沒有電梯這麼難設計了。

放在第五次的理由，大概一是有足夠的時間清明假期（不讓好好的過清明），二是有個單線程電梯的基礎。可是我仍是以爲放在第五次不太穩當，畢竟讓一個徹底沒接觸過線程的人，一個星期的時間寫出來這樣的一個工程實在要求過高。並且像我這種菜雞，在這麼短期，要理解線程，線程安全和同步之類的能夠說是天方夜譚了。

事實上在此次做業以前我徹底沒想過可以一星期「速成」JAVA多線程，好在最後犧牲了很多的睡眠時間是作出來了，雖然時間太緊作的也不怎麼樣。

設計策略：

多線程按照指導書設計，三個電梯各一個線程，調度器一個線程，輸入一個線程。

此次比起第三次ALS的電梯改動仍是挺大的，最明顯的是調度器再也不是一個GOD類，電梯的運動也是分配給了elevator類。

然而提及來容易，實施起來確是無比困難。

首先是我對線程徹底不清楚，全靠速成。以至於剛開始跑的時候，一度由於while(true) 而卡死，eclipse崩潰，CPU的佔用率100%。

其次知道了線程不能直接這樣，使用了wait來使線程中止，具體說來即讓調度器在請求隊列爲空時中止工做。

另外對每個電梯都構造了一個請求隊列，電梯直接根據這個隊列來跑便可。因此此次做業，在相互的睡眠與喚醒，花了很多功夫。另外這樣會有不少共有元素，所以線程安全也很重要。爲了解決輸入END中止線程，我甚至還特意開了個類傳遞參數。

最後在調度上一度出現問題，最後發現是根據電梯狀態來判斷分配延遲太大，又來改分配。在星期三下午還臨時改了分配掉地策略。致使最後出來了不少以前沒有，意想不到的bug。

回首起來此次做業真是一次慘痛的經歷，也是多線程痛苦的開始。

度量分析：

 

 

類圖：

使用ctrl + 滾輪 獲取最佳觀賞效果。

協做圖：

 

能夠看出來，度量分析有三個點飄紅了。

圈複雜度和嵌套複雜度很高，這也是情理之中的。畢竟這個sendInLine方法大部分是沿用上次的電梯的，上次都飄紅了，然而並無時間來優化上次代碼，此次飄紅也正常。

另外一個點是類的屬性過多。問題出在調度器類中，傳了很多參數。

可是在此次難度的重壓下，對於我這個菜雞來講，優化實在不大現實，畢竟debug就要花上很多時間。在bug都沒法解決的狀況下沒辦法去面對優化和設計原則的。

因此寫完以後，缺點一大堆，bug多並且設計也很差。惟一的優勢可能就是寫出來了。

BUG總結：

本身的bug：一堆

時間有偏差（還好公測沒有出現），這個實在很難避免，在時間不足的狀況下我也沒辦法處理了。

同層應該捎帶未捎帶，多開了一次門。

STILL狀態下不能捎帶。

上述兩條是由於我開始按照電梯狀態來判斷捎帶，出問題後，臨時改爲按照另外的方式，可是沒有測試，因此出現了bug。

ER請求有一個捎帶不上，不知道緣由，多是由於鎖？

 

下家的bug：也是一堆，還更多

公測運動量沒有按照最小的來分配。

同質請求判斷出了問題。

同層請求多於一條，捎帶不上。這個是由於按照電梯狀態判斷，中間有時間偏差，對於同時輸入的請求沒法及時正確分配。

此外還出現了一個crash，是線程中出現了問題。

 

測試策略什麼的，不存在的，畢竟隨便一找就是一堆bug。

---

第六次做業：IFTTT（文件監控器）

最迷的一次，比多線程電梯還迷。

若是說多線程電梯在星期一已經大體跑出來多線程只是bug不少，此次IFTTT在星期一連個架構都沒有，在星期二才能大體跑出來。晚上一邊聽涼涼一邊寫完了。

雖然難度不及多線程電梯，可是時間緊迫，並且指導書不知所云，光是理解指導書就要費很多功夫。

此次做業說是訓練對線程安全的應用，實際上寫完以後，除了一個SafeFile類，根本沒發現線程安全在哪裏有應用。對線程安全的要求，比上次多線程電梯差遠了，甚至比不過出租車。因此徹底不能理解此次做業的意義何在。乾脆說是對文件類的訓練徹底不爲過。

另外但願下屆此次做業指導書能更清晰，不要朝令夕改，畢竟星期三下午還要改需求讓咱們仍是挺難受的，作好測試時候測試點和設計需求的平衡，最好直接刪除IFTTT此次做業。

 

設計策略：

輸入一個線程，每個 「觸發器-任務」 對 對應一個線程，即爲每個監視器開一個線程，最多可能100個。

此外爲detail和summary單開了兩個線程。

線程安全問題，發現只要用的是SafeFile，不會由於線程安全而出錯，出錯的只多是實現上的。

因此最困難的仍是實現，線程安全我基本上沒注意到然而也沒有出問題。

度量分析：

 

 

類圖：

使用ctrl + 鼠標上滾輪獲取最佳觀賞效果。

協做圖：

飄紅的點是圈複雜度和嵌套深度，所有出在rename方法上（除了這個方法估計就是path-changed方法）

由於一個方法中涉及的太多。這也跟設計策略有關，由於每個線程對應的一種方法。除此以外，快照snapshot也在方法中進行，所以這圈複雜度和嵌套深度都很高。

BUG總結：

雖然本身感受寫的不是很好，應該會有bug，然而實際被測試中並未被找到bug，也是很值得高興的。

測試下家過程發現了兩個bug，公測發現監控文件夾renamed的recover沒法恢復，在監控文件夾path-changed的recover也沒法恢復。另外一個bug是監控文件夾modified，在size-changed同時不會觸發。

至於測試策略，按樹測吧。畢竟除了樹也沒什麼好測的。（樹上的也不能所有測完）

---

 第七次做業：傻瓜出租車

據說是簡單了，然而實際上動手的時候發現本身又被騙了。

不過比起最難的多線程電梯，以及最迷的IFTTT來看，確實是簡單了點。雖然沒簡單到比前三次簡單就是了。

總體思路和架構由於有了多線程電梯，看起來不是那麼困難了。並且實現上由於有隨機性，因此更不會跟電梯同樣有明確的bug可尋。

可是花的時間並無減小太多。。。。。

 

設計策略：

徹底按照電梯的思路，輸入一個線程，調度一個線程，此外把100個出租車單開一個線程。

此次調度比電梯簡單的緣由是分配任務後沒捎帶，也就是說沒必要再考慮出租車的調度，直接讓出租車運行便可。不會像電梯同樣，分配了任務以後，電梯還要考慮到本身被分配的任務來運行。

設計看起來不太難，主要仍是實現部分。

度量分析：

 

 

類圖：

使用ctrl + 鼠標上滾輪獲取最佳觀賞效果。

協做圖：

 

第一個飄紅的點圈複雜度來自GUI ？ 就不作評述了。

後面嵌套深度過深來自run方法，應該是scheduler的run方法。這塊寫的太複雜了致使飄紅。

此次由於有設計原則的限制，在設計上稍微下了點功夫。所以自我評價還行。

BUG總結：

己方惟一bug仍是時間的偏差，沒法作到很精確的200ms，感受要實現仍是很困難的。

對方的bug除了個人以外，還有加信用時間沒有作到與指導書相同。

此次的測試策略仍是按照樹測，由於隨機性過高，找不到其餘測試方法。

---

 心得與體會：

 1.先說下收穫。從清明以前，徹底不知道多線程爲什麼物，在寢室啃着教程學習多線程，到現在已經能寫出三個多線程程序，要說內心面沒有點成就感是不可能的。

最大的收穫就是對多線程有了必定的理解，不像一開始同樣，漏洞百出，什麼都不會，寫一段代碼能把電腦炸半天。如今不只能寫出來多線程程序，對多線程的debug也有計可施。也對多線程安全有了必定理解。

2.對於線程安全的理解，不只僅只是用synchronized簡單鎖一下方法，一開始用這個方法在debug過程當中吃了很多虧。什麼時候synchronized，什麼時候wait，什麼時候notify，須要開始就有一個大致的把握。

3.因此在設計線程的時候就要考慮好線程同步問題，否則debug會有苦頭吃。

4.至於設計原則，雖然在開始幾回比較困難的時候，真的是沒有時間來考慮本身的設計。可是在還算充足時間的出租車上，一個好的設計做用仍是很大的。

5.有得也有失。失去的睡眠時間和頭髮固然微不足道，真正令我心痛的是失去的其餘課程的時間。由於花了太多時間在oo上，os前一天基本沒有時間複習os的理論，實驗也只是粗略的看看。致使os次日的考試一塌糊塗，三次實驗上機掛了兩次，這是讓我最遺憾的。但願後來人能協調好oo與os的時間。也但願oo的課業壓力可以小一點點，熬夜真的不算什麼，可是我真的不但願os掛科。。。。。

 

 

6.....大概不算一點吧

感受Avicii的waiting for love 挺符合oo的意境的

Monday left me broken
Tuesday I was through with hoping
Wednesday my empty arms were open
Thursday waiting for love, waiting for love　

但願以後的測試者都能滿懷愛心