0、結對人員

　　Hu(155) Tan(189)

1、關于結對編程

　　優點：coder的大部分錯誤可以在第一時間被reviewer發現，這省下了很多本應當在項目測試階段花費的時間；

　　　　 ??結對編程寫出的每一個程序都體現了兩個組員中的較高水平；

? ? ? ? ? ? ? 兩個人輪流交換角色開發項目，加快項目進展速度；?

? ? ? ? ? ? ? 兩個人結對開發的過程就是兩個人互相學習進步的過程。

　　缺點：有時候reviewer會整段時間處于無事可做的狀態；

? ? ? ? ? ? ? 增加了意見統一成本。

　　Tan的優缺點：（優）接受新事物的能力強，在很短時間內理解了項目的基本框架；（優）算法設計水平高；（優）有追求卓越的精神，最終定下的版本是在最初版本的基礎上進行了N次修改得到的，最后的平均花費時間僅僅是第一個版本的1/5；（缺）編程風格還是繼續延續面向程序的。

　　Hu的優缺點：（優）算法水平還算過得去；（優）思維嚴謹，查錯能力還算過得去；（優）和Tan大神的影響下追求卓越的精神還算過得去；（缺）開發大項目的經驗不足，框架看了很久沒。

（附上結對照片）

2、ASE的設計方法

　　信息隱蔽：類的成員變量的可見性統一成private，并設計相應的屬性。

　　接口設計：設計接口是盡量細化，功能追去單一，不要設計功能臃腫的接口方法。

　　松散耦合：在一個系統中使各組件在最小的可行范圍內彼此依賴，盡量限制類和類之間互相連接。

　　契約式設計：在調用方法前保證初始條件的正確性。

3、單元測試

4、UML類圖

5、電梯調度的算法　　

　　先描述一下bus的算法，無視需求，每層依次停。

　　首先，我們分析了一下這個算法，這個算法很顯然可以保證將每個人送到，但效率很低。

　　bus算法效率低的原因在于停了很多不需要停的樓層。

　　按照我們平常乘坐電梯的思想，很容易想到是哪一層按了電梯，電梯就去哪層，并不停中間層的。

　　這樣，我們只需要記錄電梯需要去哪層，把電梯派過去就可以了。

　　考慮兩個變量，電梯、樓層。可以說這是一個二維的模型。由于二維模型處理比較麻煩。退化為兩個一維。

???? （1）每個elev查找最適合的req

　　（2）每個req查找最適合的elev（離它最近的一個elev）

　　由于總感覺(2)有點問題，并結合編碼，我們選擇的方案(1)

　　對于方案(1)，何為最適合的req呢

　　如果電梯處于運行狀態，則查找電梯當時位置與要去的位置時，是否有人要進電梯，如果有，順路把那人帶上

???? 如果電梯處于停止狀態，則按如下順序查找（在樓下往下走的，在樓下往上走的，在樓上往上走的，在樓上往下走的）

　　至于為什么是這個順序，多次實踐得到的結果

　　最后，有個小優化，即電梯空閑體重小于100，就視為超重，不停了

　　至于為什么是這個數，也是多次實踐得到的結果

?

　　對于如何實現這個算法，我們存儲了兩個信息

　　_wait記錄還沒有進去電梯的req

　　elevStop[]記錄該電梯將要去的樓層

　　當電梯處于停止狀態時，若elevStop[]不為空，找到elevStop[]中最近的那個樓層去，若elevStop[]為空的時候，在_wait中找到最合適的樓層去

　　當電梯處于運行狀態時，在_wait中尋找是否可以中途帶人，可以的話將該樓層加入elevStop[]中，并將目標改為該樓層

?

胡仁君 2012/10/22

轉載于:https://www.cnblogs.com/hurj/archive/2012/10/22/2733189.html

總結

以上是生活随笔為你收集整理的Pair Project: Elevator Scheduler Report By Hu Renjun的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。