結對專案小記
——by 12061227 康 12061179 宇帆
結對程式設計就是一種敏捷軟體開發的方法，兩個人在一個計算機上共同工作。一個人輸入，而另一個人檢查他輸入的每一行程式碼。輸入程式碼的人稱作駕駛員，審查程式碼的人稱作觀察員（或導航員）。兩個程式設計師經常互換角色。
在結對程式設計中，觀察員同時考慮工作的戰略性方向，提出改進的意見，或將來可能出現的問題以便處理。這樣使得駕駛者可以集中全部注意力在完成當前任務的"戰術"方面。觀察員當作安全網和指南。結對程式設計對開發程式有很多好處。比如增加紀律性，寫出更好的程式碼等。
結對程式設計的優點在於每人在各自獨立設計、實現軟體的過程中不免要犯這樣那樣的錯誤。在結對程式設計中，因為有隨時的複審和交流，程式各方面的質量取決於一對程式設計師中各方面水平較高的那一位。這樣，程式中的錯誤就會少得多，程式的初始質量會高很多，這樣會省下很多以後修改、測試的時間。具體地說，結對程式設計有如下的好處：
兩個人的激烈討論產生了很多靈感，在我們在討論中，常常會想到非常好的點子來解決在程式設計過程中不斷出現的新問題。 
對我們自身來說，結對工作能帶來更多的信心，高質量的產出能帶來更高的滿足感。
在心理上, 當有另一個人在你身邊和你緊密配合, 做同樣一件事情的時候, 你不好意思開小差, 也不好意思糊弄。
增強程式碼和產品質量，並有效的減少BUG。
總之，如果運用得當，結對程式設計能得到更高的投入產出比（Return of Investment）。
結對程式設計的缺點我認為在於
完成同一個功能的程式碼可能不同人實現的方式是不一樣的，假設他們寫出來的都是很優質的程式碼。這個時候就需要結對雙方都能夠意識到並承認這一點。結對的本質是用兩個人的大腦拼接出最優質的程式碼，如果程式碼已經是最優了，那就無需對這段程式碼妄加評論了。這樣就產生了反效益的產出
有時候，程式設計師們會對一個問題各執己見，爭吵不休，影響工作效率
有些程式設計師不喜歡在工作的時候身後/或旁邊 有人盯著，有一種被監視的感覺。
有的人認為編碼要進行獨立思考，而獨立思考過程是一個私人的問題，有問題可以在專門的會議上討論，但當你在分析處理具體問題時候總有人在旁邊囉裡八嗦的時候不會感到愉快。
有經驗的人更喜歡單刀直入，找個人來站在他背後看著他可能會讓他感到非常的不適，最終導致程式設計時受到情緒影響，反而出現反作用。
安康同學的優點在於：1.工作非常認真 2.工作過程中積極向上，充滿熱情。3.工作效率奇高，有很多非常好的點子。
劉宇帆同學的優點在於：1.工作態度良好，所以很少發生爭執。 2.對工作方向態度樂觀 3.具有較好的分析能力
劉宇帆同學的缺點在於：個人技術能力不夠強
Information Hiding, interface design, loose coupling 的應用
Information Hiding即資料隱藏，在物件導向的程式設計過程中，使得一個模組內包含資訊(過程或資料)，對於不需要這些資訊的其他模組來說，是不能訪問的。在物件導向方法中，資訊隱蔽是通過物件的封裝性來實現的。實現方法可以是類的成員變數的可見性統一成private，並設計相應的屬性。
interface design即介面設計，它的優點在於使程式具有良好的封裝性，便於擴充套件功能而不影響原來的類是封裝的一個主要的好處，就是增加軟體程式碼的內聚性。通過增加內聚性，進而提高可複用性和可擴充套件性。介面能夠提供給後面的程式設計一個巨集觀的控制，我們通過介面能很快的知道電梯、乘客的排程方案、請求都有哪些屬性，要實現哪些方法，而不用關心具體的實現細節。
loose coupling即鬆耦合，軟體功能模組的設計和劃分按照OO（物件導向）的思想，遵循"強內聚，弱耦合"的原則，也就是儘量將相互依賴的類放在一個名稱空間（包）中，內部結構和聯絡要儘量緊密——強內聚；對外模組儘量與其他方法或功能減少 耦合---弱耦合 ，以便功能上或程式碼上可以達到重用，再組合新功能的時候，可以像搭積木一樣，分別拿出去再重用，而不會太關聯其他。
Pair Work中的Design by Contract, Code Contract
在Design by Contract（契約式設計）的模式中，這是一種設計計算機軟體的方法。這種方法要求軟體設計者為軟體元件定義正式的，精確的並且可驗證的介面，這樣，為傳統的抽象資料型別又增加了先驗條件、後驗條件和不變式。這種方法的名字裡用到的"契約"或者說"契約"是一種比喻，因為它和商業契約的情況有點類似。
在這種模式下，優點是使用者和被呼叫者地位平等，雙方必須彼此履行義務，才可以行駛權利。契約所核查的，是"為保證正確性所必須滿足的條件"，因此，當契約被破壞時，只表明一件事：軟體系統中有bug。雙方都有必須履行的義務，也有使用的權利，這樣就保證了雙方程式碼的質量，提高了軟體工程的效率和質量。
在Design by Contract（契約式設計）的模式中缺點也是不可避免的，由於契約的限制比較大，在有的模式存在有改動的時候變更的部分會更多，而且契約式程式設計需要一種機制來驗證契約的成立與否。而斷言顯然是最好的選擇，但是並不是所有的程式語言都有斷言機制。那麼強行使用語言進行模仿就勢必造成程式碼的冗餘和可讀性的降低。
UML類圖
