結對專案內容：
結對成員：康家華，馬騰躍（
[附加題]第四階段目標 -介面模組，測試模組和核心模組的松耦合。
對於這個附加題，我們小隊（a）決定和劉幹小隊（b）的模組進行交換，於是在拿到對方的**時，我們立刻就傻眼了。
不是說對方寫的很差，相反，b小隊的**有劉幹的保證，質量很高。讓我們傻眼的是因為我們的想法不是完全相同的，而我們設計的介面的要求和他們設計的介面的要求不同，導致介面模組、測試模組不能和他們封裝好的core進行銜接。
所以現在怎麼辦？可以說，我們設計的這三個模組——核心模組、使用者介面模組和測試模組——在開始時就是銜接好的。測試模組就不用說了，根據介面和各種分支設計出來的能夠99%+覆蓋核心**的測試用例；使用者介面模組也是一樣，或者說核心模組在一定程度上是為了使用者介面模組進行了一些修改。於是，現在就處於一種「牽一髮而動全身」的狀態，到底要不要為了契合b小隊的**而進行修改呢？
為什麼會出現如今這種情況？我是這樣理解的：首先，主觀能動性決定了我們必定有著不一樣的想法，我們在對需求分析的時候不能做到百分之百地一致；其次，多樣的編碼方式和設計方式也決定了我們很有可能產生差別，比如我使用了另乙個函式來進行引數的設定，而你通過傳參的方式設定了引數；最後，我們兩個小隊分開作業，兩者之間也沒有交流過，可能產生「蝴蝶效應」，從一開始很細小的偏差（如乙個函式的返回型別）到最後形成很大的區別（如乙個類的功能）。
思前想後，用一種最中立，最優化的方法來進行修改——取長補短。取精華去糟粕，用對方更好的想法來填自己的空缺，我們覺得有特色的保留下來，他們做的比我們好的部分我們借鑑。就比如說我們在看了b小隊的介面後，參考著他們的介面也做出了計算器的按鈕介面來。
[附加題]第五階段目標 -通過增量修改的方式，改進程式，完成對各種錯誤情況的處理。
「改進程式」這個過程其實我們一直都在進行，從一開始的程式設計起，我們就在邊寫邊改。
同樣的，我們在錯誤處理上也是邊寫邊想，我們在核心**中進行了許多錯誤情況的處理——異常丟擲。比如說：
calculate中丟擲了這些異常：
produce中丟擲了這些異常：
judge中丟擲了這些異常：
setting中丟擲了這些異常：
總的來說，我們考慮了很多，這也是上學期物件導向課程留下來的習慣（病根），也就是因為這個習慣（病根），我們在寫程式的時候總是考慮很多（沒有用的東西）。
結對專案部落格（附加題）
附加題 為 第四和第五階段 也就是 附加題 第四階段目標 介面模組，測試模組和核心模組的松耦合。和 附加題 第五階段目標 通過增量修改的方式，改進程式，完成對各種錯誤情況的處理。附加題 第四階段目標 介面模組，測試模組和核心模組的松耦合。我們選擇的互相測試的另一組也是用c 和mfc編寫的，因為其他同...
北京地鐵 結對專案 附加題
團隊成員 楊金鍵 謝振威 金豪 要求描述 使程式支援不同城市的地圖。請讓程式能處理上海的地鐵地圖，或者其它城市的地圖。把程式由 固定處理乙個地圖 公升級為 能處理多個地圖 程式的什麼模組需要變化？其實，在我們設計程式之初就已經考慮到了程式將來的可擴充套件性，所以無論是地圖儲存檔案還是 我們都是從這個...
附加題 結對程式設計 電梯排程問題的擴充套件UI介面實現
首先，不得不說因為助教給的這個 的問題，實在是不好做介面 我們的思路就是用介面盡可能地展現出排程的過程並顯示出最終的結果，這個結果其實包括兩方面，平均時間是必須的，還有就是最終的狀態，這個對比起初始資訊的狀態還是可以看出一定的效果的 另外，由於測試資料報含3個時間段，設計乙個可以讓使用者自由選定模擬...