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

?

結(jié)對編程人員

177 吳淵淵

193 薛亞杰

?

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

?

?

說明結(jié)對編程的優(yōu)點(diǎn)和缺點(diǎn)。

?

優(yōu)點(diǎn)： ? 程序員之間可以互相幫助，得到能力上的提高；

　　　　增強(qiáng)和提高代碼的質(zhì)量，并可以有效的減少BUG；　　

　　　　降低學(xué)習(xí)成本，共享編程經(jīng)驗(yàn)可以使得代碼工作時(shí)間大大減少；

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

缺點(diǎn)： ? 程序員的磨合需要時(shí)間，

?

優(yōu)點(diǎn)：coder的大部分錯誤可以在第一時(shí)間被reviewer發(fā)現(xiàn)，這省下了很多本應(yīng)當(dāng)在項(xiàng)目測試階段花費(fèi)的時(shí)間；

　　　　?? 結(jié)對編程寫出的每一個程序都體現(xiàn)了兩個組員中的較高水平；

????????????? 兩個人輪流交換角色開發(fā)項(xiàng)目，加快項(xiàng)目進(jìn)展速度；

????????????? 兩個人結(jié)對開發(fā)的過程就是兩個人互相學(xué)習(xí)進(jìn)步的過程。

　　缺點(diǎn)：有時(shí)候reviewer會整段時(shí)間處于無事可做的狀態(tài)；

????????????? 增加了意見統(tǒng)一成本。

結(jié)對的每一個人的優(yōu)點(diǎn)和缺點(diǎn)在哪里?(要列出至少三個優(yōu)點(diǎn)和一個缺點(diǎn))。

薛亞杰的優(yōu)點(diǎn):努力

　　　　　　信息檢索能力比較強(qiáng)

　　　　　　代碼功底還可以...

薛亞杰的缺點(diǎn):長期coding導(dǎo)致過于急躁

　　　　　　面向?qū)ο蟮乃枷肭啡?..寫代碼一寫就是一大坨

?

吳淵淵的優(yōu)點(diǎn):認(rèn)真

　　　　　　有毅力

　　　　　　樂于學(xué)習(xí)新知識

吳淵淵的缺點(diǎn):代碼功底過弱，給對方的工作帶來很大的不便（其實(shí)沒有。。。這是當(dāng)事人的謙詞。。。）

?

?

看教科書和其它資料中關(guān)于?Information Hiding, interface design, loose coupling?的章節(jié),說明怎樣利用這些好的設(shè)計(jì)方法。

ASE的設(shè)計(jì)方法

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

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

　　松散耦合：表示易于維護(hù)，易于測試，易于擴(kuò)展的程度，松耦合值越高，系統(tǒng)就越容易維護(hù)。

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

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

　　契約式設(shè)計(jì)：在調(diào)用方法前保證初始條件的正確性。

信息隱藏、接口設(shè)計(jì)、松耦合都是面向?qū)ο笤O(shè)計(jì)的重要方法，都是使程序設(shè)計(jì)時(shí)更接近日常認(rèn)識，在大模塊之間關(guān)系中不用過于擔(dān)心細(xì)節(jié)，只需在模塊設(shè)計(jì)時(shí)下功夫。

?

看?Design by Contract, Code Contract?的內(nèi)容:描述這些做法的優(yōu)缺點(diǎn),?說明你是如何把它們?nèi)谌肽愕淖鳂I(yè)中的。

?

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

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

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

在我們的代碼中，對于模塊間使用了契約的思想，保證雙方地位的平等。調(diào)用者的傳入?yún)?shù)必須是正確的，否則責(zé)任不在被調(diào)用者，而在傳入者。

?

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

?

?單元測試這個東西一直不會啊臥槽...這次好不容易實(shí)現(xiàn)了一個面向?qū)ο蟮拇a,結(jié)果好多方法給我蹦出來一個這個啊臥槽...

?

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

?

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

?

不要在意這些細(xì)節(jié)!（好吧我正在學(xué)習(xí)。。）

?

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

?

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

?

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

當(dāng)然staruml還是王道

說明你的算法的關(guān)鍵 （不必列出源代碼）, 以及獨(dú)到之處。

?

掃描每一部電梯,對當(dāng)前電梯選擇最適合的請求

如果電梯處于靜止?fàn)顟B(tài)(Direction.No):

1.電梯的目標(biāo)列表不為空,那么選擇距離當(dāng)前樓層最近的樓層前往

2.電梯的目標(biāo)列表為空,那么從請求隊(duì)列中選擇最合適的前往（何為最合適的：通過實(shí)踐檢驗(yàn)，按照下下，下上，上上，上下的順序選擇）

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

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

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

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

?

算法關(guān)鍵:

?

臥槽..debug了兩天半,最后發(fā)現(xiàn)問題出現(xiàn)對于QueueReq()這個方法的重寫,原來的bus算法因?yàn)楦静豢紤]乘客的請求而在每一層都停,所以它一股腦的把乘客的全部外部請求都壓入隊(duì)列了;而我們的算法需要考慮乘客是否在電梯內(nèi),所以這里需要判斷乘客的請求類型(RequestType),如果是外部請求(RequestType.DirectionReq),那么將其加入請求列表中;如果是內(nèi)部請求(RequestType.DestinationReq),說明該乘客已經(jīng)在電梯內(nèi)部,那么只需將該請求加入相應(yīng)電梯對應(yīng)的目標(biāo)列表中就好....臥槽臥槽...就這個點(diǎn)debug了兩天半啊...我說電梯怎么一直不讓人進(jìn)......

?

獨(dú)到之處:

?

目前的算法還算可以,對于電梯處于靜止?fàn)顟B(tài)時(shí)他會選擇離當(dāng)前樓層最近的目標(biāo)樓層前往,如果目標(biāo)樓層為空那么會選擇請求列表中最合適的前往,而如果請求列表為空那么根據(jù)樣例分析,他會優(yōu)先前往0層和1層,而如果不為空,那么根據(jù)多次測試,他會按照下下,下上,上上,上下的順序選擇目標(biāo).

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

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

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

如果換成博客上面要求的電梯容量,那么必然速度會加快好多...運(yùn)行后發(fā)現(xiàn)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

?

?

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

不過實(shí)際執(zhí)行過程中運(yùn)行效果反而不如不采用理想...

?

轉(zhuǎn)載于:https://www.cnblogs.com/oldoldb/p/3352177.html

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。