如果用兩個字來形容這次的任務,那一定是"臥槽"

?

結對編程人員

177 吳淵淵

193 薛亞杰

?

照至少一張照片,?展現兩人在一起合作編程的情況。

?

?

說明結對編程的優點和缺點。

?

優點： ? 程序員之間可以互相幫助，得到能力上的提高；

　　　　增強和提高代碼的質量，并可以有效的減少BUG；　　

　　　　降低學習成本，共享編程經驗可以使得代碼工作時間大大減少；

　　　　互相討論問題。更快更有效的解決問題。

缺點： ? 程序員的磨合需要時間，

?

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

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

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

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

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

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

結對的每一個人的優點和缺點在哪里?(要列出至少三個優點和一個缺點)。

薛亞杰的優點:努力

　　　　　　信息檢索能力比較強

　　　　　　代碼功底還可以...

薛亞杰的缺點:長期coding導致過于急躁

　　　　　　面向對象的思想欠缺...寫代碼一寫就是一大坨

?

吳淵淵的優點:認真

　　　　　　有毅力

　　　　　　樂于學習新知識

吳淵淵的缺點:代碼功底過弱，給對方的工作帶來很大的不便（其實沒有。。。這是當事人的謙詞。。。）

?

?

看教科書和其它資料中關于?Information Hiding, interface design, loose coupling?的章節,說明怎樣利用這些好的設計方法。

ASE的設計方法

　　信息隱藏：它的基本原則是隱藏代碼的復雜性，是提高代碼重用性和標準化的基礎。使用戶不用關心類里面的具體結構，在對象的設計過程中，將對象用于交互的外部信息和只　　　　 ? ? ? ?用于自身實現的內部信息區分開來，實現內部信息的生成和處理過程對其他對象的隱藏，保證對象內部具體實現的改變不會對整體應用造成影響。我們只關注操作的 ? ? ? ? ? ? ? ? ? ?方法，而不關注方法是怎么實現的。類與類之間交換信息時，要交流私有變量時，要用事先設計好的方法來訪問，例如，我們在其它類里面調用另外一個類的私有變 ? ? ? ? ? ? ? ? ? ?量，那么我們必須定義一個獲得該類私有變量的方法；要在另一個類里面改變另外一個類里面的變量時，我們也要定義一個改變該類私有變量的方法。在C#里特別方 ? ? ? ? ? ? ? ? ? ?便的一點就是有set和get，我們可以很方便的定義訪問一個類私有變量的方法。

　　接口設計：接口可以將類的全部內容升華為抽象，成為子類按照指定行為規范，遵循協議約定來實現接口功能的準則。實際上，接口對抽象類提供了行為規范和行為實現分離的 ? ? ? ? ? ? ? ? ? 絕好機會，使得改寫后的抽象類更加符合“自給自足”和“松散耦合”的設計原則。一個好的接口能夠提供給后面的程序設計一個良好的框架，在這次電梯調度項目里，接 ? ? ? ? ? ? ? ? ? 口IElevator、IPassenger、IScheduler、IRequest，我們通過接口能很快的知道電梯、乘客、調度方案、請求都有哪些屬性，要實現哪些方法，這樣我們的軟件測 ? ? ? ? ? ? ? ? ? 試也變得更簡單了。

　　松散耦合：表示易于維護，易于測試，易于擴展的程度，松耦合值越高，系統就越容易維護。

? ? ? ? ? ? ? ? ? 采用類與類之間依賴性低的設計方法，使一個類與另外一個類仿佛隔開了，它們之間只是通過消息來聯系的，所以設計一類時，可以不用擔心破壞另外一個類。當代 ? ? ? ? ? ? ? ? ? ? 碼有改動時，可以不用大規模的改動我們的代碼，使得代碼易于維護，我們可以定位于一個出問題的模塊，然后對其進行修改，而且能做到不改變其它模塊的服務， ? ? ? ? ? ? ? ? ? ? 使得代碼易于測試。相應的，代碼煩人擴展性也可以在一定程度上得到提高。

? ? ? ? ? ? ? ? ? 雖然松耦合系統具有很多的好處，但緊耦合系統并非一無是處。如果兩個模塊在運行過程中需要實時交互信息，并且任何一個模塊不能獨立工作，那么，就必須選擇 ? ? ? ? ? ? ? ? ? ? 緊耦合模式來構建軟件系統。盡管從技術角度上看，松耦合系統具有一定的技術先進性，但并不是所有的軟件系統都是松耦合系統。所以，從這個角度來看，選擇緊 ? ? ? ? ? ? ? ? ? ? 耦合系統還是緊耦合系統，取決于軟件具體情況和實際需求。

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

信息隱藏、接口設計、松耦合都是面向對象設計的重要方法，都是使程序設計時更接近日常認識，在大模塊之間關系中不用過于擔心細節，只需在模塊設計時下功夫。

?

看?Design by Contract, Code Contract?的內容:描述這些做法的優缺點,?說明你是如何把它們融入你的作業中的。

?

一般的觀點，在軟件體系中，程序庫和組件庫被類比為server，而使用程序庫、組件庫的程序被視為client。根據這種C/S關系，我們往往對庫程序和組件的質量提出很嚴苛的要求，強迫它們承擔本不應該由它們來承擔的責任，而過分縱容client一方，甚至要求庫程序去處理明顯由于client錯誤造成的困境。客觀上導致程序庫和組件庫的設計和編寫異常困難，而且質量隱患反而更多；同時client一方代碼大多松散隨意，質量低劣。

而在DbC中，使用者和被調用者地位平等，雙方必須彼此履行義務，才可以行駛權利。契約所核查的，是“為保證正確性所必須滿足的條件”，因此，當契約被破壞時，只表明一件事：軟件系統中有bug。其意義是說，某些條件在到達我這里時，必須已經確保為“真”。誰來確保？應該是系統中的其他模塊在先期確保。如果在我這里發現契約沒有被遵守，那么表明系統中其他模塊沒有正確履行自己的義務。所以調用者必須提供正確的參數，被調用者必須保證正確的結果和調用者要求的不變性。雙方都有必須履行的義務，也有使用的權利，這樣就保證了雙方代碼的質量，提高了軟件工程的效率和質量。

缺點是對于程序語言有一定的要求，契約式編程需要一種機制來驗證契約的成立與否。而斷言顯然是最好的選擇，但是并不是所有的程序語言都有斷言機制。那么強行使用語言進行模仿就勢必造成代碼的冗余和不可讀性的提高。比如.NET4.0以前就沒有assert的概念，在4.0后全面引入了契約式編程的概念，使得契約式編程的可用性大大提高了。此外，契約式編程并未被標準化，因此項目之間的定義和修改各不一樣，給代碼造成很大混亂，這正是很少在實際中看到契約式編程應用的原因。

在我們的代碼中，對于模塊間使用了契約的思想，保證雙方地位的平等。調用者的傳入參數必須是正確的，否則責任不在被調用者，而在傳入者。

?

通過截屏顯示你是如何用VS?的unit test?來保證你寫的類的質量的。顯示unit test?對你的寫的類(class)?的覆蓋率

?

?單元測試這個東西一直不會啊臥槽...這次好不容易實現了一個面向對象的代碼,結果好多方法給我蹦出來一個這個啊臥槽...

?

還有好多方法根本不會編寫測試代碼啊....

?

結果最后只有一個方法能夠測試啊...類的覆蓋率挫也就是必然的了....

?

不要在意這些細節!（好吧我正在學習。。）

?

畫出UML?圖顯示各個實體之間的關系 (畫一個圖即可)

?

vs2012中,右鍵scheduler項目,查看類圖,直接生成類圖...呵呵呵呵,雖然很挫......

?

不要在意這些細節(大神告訴我是我自己不會弄...)

當然staruml還是王道

說明你的算法的關鍵 （不必列出源代碼）, 以及獨到之處。

?

掃描每一部電梯,對當前電梯選擇最適合的請求

如果電梯處于靜止狀態(Direction.No):

1.電梯的目標列表不為空,那么選擇距離當前樓層最近的樓層前往

2.電梯的目標列表為空,那么從請求隊列中選擇最合適的前往（何為最合適的：通過實踐檢驗，按照下下，下上，上上，上下的順序選擇）

如果電梯處于上行狀態(Direction.Up):

掃描當前樓層與目標樓層之間是否有請求,如果有,那么將其加入電梯的目標列表中,并將電梯的下一個停靠樓層設為所有可以搭順風車的請求中最接近當前樓層的

如果電梯處于下行狀態(Direction.Down):

掃描當前樓層與目標樓層之間是否有請求,如果有,那么將其加入電梯的目標列表中,并將電梯的下一個停靠樓層設為所有可以搭順風車的請求中最接近當前樓層的

?

算法關鍵:

?

臥槽..debug了兩天半,最后發現問題出現對于QueueReq()這個方法的重寫,原來的bus算法因為根本不考慮乘客的請求而在每一層都停,所以它一股腦的把乘客的全部外部請求都壓入隊列了;而我們的算法需要考慮乘客是否在電梯內,所以這里需要判斷乘客的請求類型(RequestType),如果是外部請求(RequestType.DirectionReq),那么將其加入請求列表中;如果是內部請求(RequestType.DestinationReq),說明該乘客已經在電梯內部,那么只需將該請求加入相應電梯對應的目標列表中就好....臥槽臥槽...就這個點debug了兩天半啊...我說電梯怎么一直不讓人進......

?

獨到之處:

?

目前的算法還算可以,對于電梯處于靜止狀態時他會選擇離當前樓層最近的目標樓層前往,如果目標樓層為空那么會選擇請求列表中最合適的前往,而如果請求列表為空那么根據樣例分析,他會優先前往0層和1層,而如果不為空,那么根據多次測試,他會按照下下,下上,上上,上下的順序選擇目標.

這次的算法只是1.0版本,如果有必要,會進行2.0,3.0版本更高效算法的設計(畢竟要跑得比bus算法還慢基本是不可能了...)

PS:BUS算法和我們的算法跑分表:(工程原始輸入文件,不是博客上面的數據要求..)

?	Bus	我們的算法
Passenger1.xml	307.05	87.65
Passenger2.xml	1024.403	443.894
Passenger3.xml	1424.563	215.943

如果換成博客上面要求的電梯容量,那么必然速度會加快好多...運行后發現passenger2.xml可以跑到250左右,passenger3.xml可以跑到180左右

?	Bus算法	我們的算法
Passenger1.xml	307.05	87.65
Passenger2.xml	665.443	261.593
Passenger3.xml	942.943	186.203

?

?

?另外，關于電梯上下班高峰的判斷，我的想法是在每一個tick執行queuereq的時候,掃描一下當前準備進入的req,根據req占count的比重來判斷是否是上下班高峰;如果req.direction=0|1的比重大于0.8,那么即可判斷是上班高峰;如果req.destination=0|1的比重大于0.8(當然這一部分必須是已經進入電梯的req),即可判斷是下班高峰.

不過實際執行過程中運行效果反而不如不采用理想...

?

轉載于:https://www.cnblogs.com/oldoldb/p/3352177.html

總結

以上是生活随笔為你收集整理的软件工程-pair work的全部內容，希望文章能夠幫你解決所遇到的問題。

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