2015結對項目
成員: 176 陳謀 178 符美瀟
我和符美瀟都有着較強的編程能力，對待人物也都能夠一絲不苟地完成，我么最大的相似之處就是性格都比較溫和。當然我們也有很多共同的興趣愛好，都喜歡打羽毛球、乒乓球，熱衷於近現代文化等。
結對編程場景
對於我們來說，結對編程並不是一件特別舒適的事情。兩個人盯着14.6寸的小屏幕看上半個小時都會覺得特別累。我門在結對編程的時候，最想做的就是每個人擁有一個顯示器，這樣我們也不會覺得太辛苦。但是這只是妄想，沒有實現。
結對編程的優點
每人在各自獨立設計、實現軟件的過程中不免要犯這樣那樣的錯誤。在結對編程中，因為有隨時的復審和交流，程序各方面的質量取決於一對程序員中各方面水平較高的那一位。這樣，程序中的錯誤就會少得多，程序的初始質量會高很多，這樣會省下很多以后修改、測試的時間。具體地說，結對編程有如下的好處：
（1）在開發層次，結對編程能提供更好的設計質量和代碼質量，兩人合作能有更強的解決問題的能力。
（2）對開發人員自身來說，結對工作能帶來更多的信心，高質量的產出能帶來更高的滿足感。
（3）在心理上, 當有另一個人在你身邊和你緊密配合, 做同樣一件事情的時候, 你不好意思開小差, 也不好意思糊弄。
（4）在企業管理層次上，結對能更有效地交流，相互學習和傳遞經驗，能更好地處理人員流動。因為一個人的知識已經被其他人共享。
總之，如果運用得當，結對編程能得到更高的投入產出比。
結對編程的缺點
由於每個人的個性不同，習慣不同，能力不同等等，他們在編程的途中可能會鬧出各種不愉快。如果沒有很強的自控力和優雅的態度，很可能雙方就會兵戎相見。具體地，我做了以下總結：
（1）對於有不同習慣的編程人員，可以在起工作會產生麻煩，甚至矛盾。
（2）有時候，程序員們會對一個問題各執己見（代碼風格可能會是引發技術人員口水戰的地方），爭吵不休，反而產生重大內耗。
（3）兩個人在一起工作可能會出現工作精力不能集中的情況。程序員可能會交談一些與工作無關的事情，反而分散注意力，導致效率比單人更為低下。
（4）結對編程可能讓程序員們相互學習得更快。有些時候，學習對方的長外，可能會和程序員們在起滋生不良氣氛一樣快。比如，合伙應付工作，敷衍項目。
（5）面對新手，有經驗的老手可能會覺得非常的煩躁。不合適的溝通會導到團隊的不和諧。
（6）新手在面對有經驗的老手時會顯得非常的緊張和不安，甚至出現害怕焦慮的的精神狀態，從而總是出現低級錯誤，而老手站在他們后面不停地指責他們導致他們更加緊張，出現惡性循環。最終導致項目進展效率低下，並且團隊貌合神離。
（7）有經驗的人更喜歡單兵作戰，找個人來站在他背后看着他可能會讓他感到非常的不爽，最終導致編程時受到情緒影響，反而出現反作用。
結對人員的優缺點
我的優點和缺點都有很多，具體來說有工作能力強，但是喜歡拖拖拉拉；擁有較好的變成習慣，但是過於追求細節，導致編程速度較慢；喜歡代碼的簡潔明了，但是過分使用冗余代碼或者效用低下的算法。
符美瀟的優點有很多，工作認真負責，工作效率高，思想很活躍；但是也有不足，如編程能力處在中等水平，喜歡睡懶覺，喜歡看電影。
好的設計方法
Information Hiding, interface design, loose coupling的利用
信息隱藏：首先，在類中，定義的變量和方法可以再前面加上一個下划線"_"來標識，這是一個好的命名規范，可以避免無意中對私有成員進行賦值。類與類之間交換信息時，要交流私有變量時，要用事先設計好的方法來訪問，這樣如果我們在其它類里面調用另外一個類的私有變量，那么我們必須定義一個獲得該類私有變量的方法；要在另一個類里面改變另外一個類里面的變量時，我們也要定義一個改變該類私有變量的方法。在C#里特別方便的一點就是有set和get，我們可以很方便的定義訪問一個類私有變量的方法。
接口設計：一個好的接口能夠提供給后面的程序設計一個良好的框架，在這次電梯調度項目里，接口IElevator、IPassenger、IScheduler、IRequest，我們通過接口能很快的知道電梯、乘客、調度方案、請求都有哪些屬性，要實現哪些方法，而不用關心具體的實現細節；這樣我們的軟件測試也變得更簡單了。
松耦合：在我們的代碼設計時，不用擔心會破壞其它地方的代碼。這種類與類之間依賴性低的設計方法，使一個類與另外一個類仿佛隔開了，它們之間只是通過消息來聯系的，所以設計一類時，可以不用擔心破壞另外一個類。當代碼有改動時，可以不用大規模的改動我們的代碼，我們只用定位於一個出問題的模塊，然后對其進行更改就好了，而且能做到不改變其它模塊的服務。
信息隱藏、接口設計、松耦合都是面向對象設計的重要方法，都是使程序設計時更接近日常認識，在大模塊之間關系中不用過於擔心細節，只需在模塊設計時下功夫。
Design by Contract, Code Contract
契約式編程對於軟件工程是一個極大的理論改革，對於C/S模式造成了極大的影響和沖擊。對於C/S模式，我們看待兩個模塊的地位是不平等的，我們往往要求server非常強大，可以處理一切可能的異常，而對client不聞不問，造成了client代碼的低劣。
而在DbC中，使用者和被調用者地位平等，雙方必須彼此履行義務，才可以行駛權利。調用者必須提供正確的參數，被調用者必須保證正確的結果和調用者要求的不變性。雙方都有必須履行的義務，也有使用的權利，這樣就保證了雙方代碼的質量，提高了軟件工程的效率和質量。
缺點是對於程序語言有一定的要求，契約式編程需要一種機制來驗證契約的成立與否。而斷言顯然是最好的選擇，但是並不是所有的程序語言都有斷言機制。那么強行使用語言進行模仿就勢必造成代碼的冗余和不可讀性的提高。比如.NET4.0以前就沒有assert的概念，在4.0后全面引入了契約式編程的概念，使得契約式編程的可用性大大提高了。此外，契約式編程並未被標准化，因此項目之間的定義和修改各不一樣，給代碼造成很大混亂，這正是很少在實際中看到契約式編程應用的原因。
在我們的代碼中，對於模塊間使用了契約的思想，保證雙方地位的平等。調用者的傳入參數必須是正確的，否則責任不在被調用者，而在傳入者。
單元測試
這是我們單元測試最后的截圖，雖然還有很多測試點沒有完全被測到，但是從測試效果來看，這次的作業完成效率還是很高的。當然，我們還需要努力，在很多過程中沒有完全發揮自身力量。
為了更好的完成測試覆蓋率，我們應該分析每個測試點，分析這些測試點的類別，從而有針對、有選擇地進行測試，從而讓測試效果不斷完善，測試結果不斷增強。
類圖
由於Vs類圖之間的聯系不夠緊密，很多聯系被忽略掉，所以會看到個別孤立的類。當然，這些之間的連線雖然沒有出來，但是通過方法名可以很容易找出一些關系來。
算法的關鍵和獨到之處
我的算法中比較獨特的地方應該是四則運算這部分。大部分同學在寫四則運算的過程中，或多或少會將其改成后綴表達式，然后再用堆棧的方式來進行運算。但是這樣做的話，步驟比較繁雜，不容易做出來。所以我改用了一個原ACM競賽中的編程算法。
然后比較關鍵的一點就是生成表達式的方法：我用了編譯原理書中的一個方法，而且這個方法十分利於對后續編程的修改。
<表達式> = <項> | <表達式> + <項> | <表達式> - <項>
<項> = <因子> | <項> * <因子> | <項> / <因子>
<因子> = (<表達式>) | i
通過這種文法表達式，我能夠采用很簡便的方式實現，而且運算速度也比較快。
感想與體會
這次作業要求很多，我花在其中的時間也很多，但是我很開心，因為我學會了很多以前沒有接觸到的東西。
人生就是這樣，或許此刻勞累受苦，但是將來某個時刻將會因為這個時候的奮斗而少做很多事。當然，為了以后能夠更為快速的掌握市場經濟的需要，找准自己的位置。如此才能最大限度地讓自己活得更加精彩。