關於電梯排程系統，我們的想法很簡單，做乙個最簡單的電梯。那麼最簡單的電梯有哪些標準呢？首先，靜止時，某層有人按鈕，會響應。在行進過程中，遇到正方向的響應（所謂正方向的響應，必須符合兩個條件：1.電梯的行進方向和人所要去的方向一致2.人在電梯當前的行進方向上）會停止。人滿不停。但是，考慮到有四個電梯，不同的排程方式對效率的影響很大。因此還需要去做乙個選擇，選擇哪個電梯去響應需求。那麼，該如何去選擇呢？簡單來講，對此刻靜止的電梯（未工作的電梯）和正方向電梯（人未滿）按照離需求響應的距離排序，最近的優先響應需求。這樣的話，就存在乙個問題，可能某個需求沒有電梯響應，比如所有的電梯都是逆向電梯或者人滿。所以，進一步的解決這個問題，就需要另乙個機制，保證實時響應，系統有個自帶的時鐘週期tick，恰好每個tick，都會執行run()這個函式。我們應該很好的利用這個機制，這樣的話，每個tick都做一次四個電梯的決策，這樣的話，對於某個響應，如果一開始沒有電梯符合條件可以響應，那麼每個tick都做一次決策，最會有乙個時間有電梯符合要求去響應這個需求。同時，這樣的好處，也解決了如果乙個電梯已經響應某個需求，但是在行進的途中被截斷，從而不再滿足要求，進而剛開始的需求沒辦法滿足的問題。因為通過這樣的實時機制，只要需求沒被滿足，每個tick都會發出一次需求響應，如果暫時要求被滿足但是中途被截斷從而不再滿足，那麼下乙個tick還會再發出需求響應。
經過如上的分析，我們設計了move類，moving類，run類，record類，move是讓電梯做正常的往復運動，到最高層停然後向下運動，到最低層停然後向上運動。record是記錄下目前電梯裡所有人要去哪層，同時需要返回nearest此刻最近的樓層是哪一層。moving是實際的電梯運動情況，在做move時，將電梯停在nearest，然後繼續move。run是要對四個電梯做乙個選擇，選出此刻要響應需求的電梯具體是哪乙個。
但是，由於整個專案有點複雜，最後這個想法沒有實現。退而求其次，只是在原來最壞的基礎上改為如果某層沒人要上，也沒人要下的話，電梯就不停。這樣的話，沒有考慮到四個電梯的選擇問題，但是一定程度上也比bus的演算法提高了效率。
最後，這不算是次成功的作業，要學的東西還很多，前面要走的路還很長。
關於結對程式設計的好處：
1、兩個人可以討論，不用的思路結合起來往往能有意想不到的收穫！
2、兩個人可以互補，專案做來更容易。
3、兩個人可以互相監督、互相督促。
關於結對程式設計的壞處：
兩個人如果都犯懶的話，互相靠對方，最後可能會得不到理想的效果。
關於結對程式設計作業
第一次作業由於種種原因，做的很失敗，不想再說什麼了。一天改兩次作業要求的老師頭一次見，都懶得再吐槽了。千言萬語早已匯成乙個字。關於結對程式設計作業，也是第一次見放假前不留作業，假期過了兩天再留作業的老師。還是不說了，說得我自己都覺得煩了。周二晚上和這次結對作業的partner吳瀚雄討論了一下作業要求...
結對作業二
gitbub鏈結位址 資料輸入鏈結 資料生成程式的原理考慮的因素 學生 意願，時間，標籤無重複 部門 時間，標籤無重複 1 建模 處理過程分為輸入資料處理 input 匹配 match 匹配結果輸出 output 輸出處理模型 將學生與部門抽象成類 部門 2 匹配演算法的實現 考慮因素 重要性從高到...
結對作業一
李嘉群 061500513 劉雙玉 031502424 針對單個學院的部門 學生互選系統。只完成宣傳到最終錄取的過程，不包括後續管理。至於原因，總覺得如果志願填報跟福大教務處在一起會很怪異，說白了也是懶。1 n need,需求 部門痛點 針對題目需求 由於不考慮實現 貌似下次作業也不是實現 那就在這...