結對人員：楊金鍵 謝振威 金豪（順序無特殊含義，僅因**從左到右這個順序）
結對程式設計優點：及時發現bug，糾正程式設計習慣，及時糾正可能帶來問題的程式設計思路。
缺點：效率太低，時間開銷大。效率太低最主要的體現，便是溝通。當a寫完parta後b在使用parta的過程中，很可能a的時間已經有了別的安排，並不能及時回覆b在使用parta中遇到的問題，當b需要a對parta進行修改時，a覺得自己寫的就很好是b強行想要那樣的介面，之類等等溝通中的問題，都會開銷較大時間。同時因為我們是三人組，人員不在同乙個宿舍，大三課表個人隨意度大，要讓大家都坐在一起程式設計時間利用率低，平時一天也就只有幾個小時可能。
個人優點：
金豪：積極主動，想法靈活，認真學習
謝振威：刻苦努力，**質量高bug較少，認真負責
楊金鍵：認真刻苦，勤於實踐，思路明了
個人缺點：
金豪：遇到奇怪問題。。
謝振威：悶聲發大財
楊金鍵：眼高手低，當修復bug的時候經常改這裡忘了那裡，導致產生新的bug。。動手能力還是太差了。
設計方法：
在動手寫**之前先進行周密的設計，包括各個模組的功能，模組之間的具體介面。關鍵在於介面，隊員之間一定要協商好後行動，不然在後續程式設計中容易產生各式各樣的bug。同時模組內部的屬性應當不能由其他模組直接訪問，即應當通過get/set方法（如需要被訪問）才能被其他模組進行訪問。同時當兩個模組由不同的人寫的時候，這個時候我們可以預先寫好乙個中間層，然後依據中間層各自進行各自的設計確保和中間層的鏈結。
契約式設計：
最初是被bertrand meyer在設計他的eiffel語言時所創造的概念，並且在2023年開始逐漸被各式各樣的**引用。用文件來記載權利和義務的說明並用程式來檢驗，這就是契約式設計的核心。契約式設計其之所以得到了人們的重視，因為它將責任的分工明確化。當一段**發生異常時，我們過去的思想總會模糊的認為，是否是這段**本身存在錯誤？而程式的規格化設計明確地告訴了我們這一錯誤的責任到底在於使用者還是設計者。在物件導向技術中，介面是我們在物件導向中需要關心的東西，可是只有藉口這卻還不夠充分，我們究竟如何才能正確的使用介面，而這恰恰是契約式設計所提供的部分。只有考慮到了規格，才可能實現物件導向的目標：可靠性，可擴充套件性，和可復用性。
覆蓋率：
測試方面，我們是採用vs2015針對計算模組專門新建專案做的測試（也打包在隨後的**庫裡面）。測試用力基本涵蓋了所有的可能情況，具體如下：
以及**覆蓋率是這樣的：
uml圖：
演算法關鍵：
演算法關鍵與上次的完全相同，圖形介面並未用到任何高深演算法，都是簡單的拼接，地圖計算採用了迪傑斯特拉演算法，對與最少換乘，使一次換乘增加的距離遠大於增加乙個站增加的距離。在圖形介面上，站作為按鈕出場，存放在乙個vector中，每次重畫直接移動vector中的按鈕，對於線路則是直接重畫，動畫則是通過qt的訊號與槽來實現，乙個執行緒每隔乙個單位時間（並非1ms而是指編者設計的一小段時間）發出訊號，畫布執行緒通過槽函式收到訊號進行動畫。
附加題：
github位址（含可執行程式）
結對專案 地鐵出行路線規劃程式（續）
一 結對程式設計情況簡介 1.結對程式設計小夥伴 石浩然 陳彥吉 2.結對程式設計大致流程 複審 除錯 模組化 ui開發設計 異常處理 單元測試。如下 3.結對程式設計優缺點 4.小夥伴們的優缺點 以下部分來自隊伍公共部分 二 設計方法 當開發乙個完整的程式時，可將程式的每個組成部分封裝在乙個模組中...
結對專案 地鐵出行路線規劃程式 續
圖形化使用 隊友的優缺點 因為本次程式要求能同時計算換乘最少和站點最少，因此我在原本的計算最短路徑的spfa演算法的基礎上增添了路由表功能，每個能到達的節點都擁有一張路由表，表示到達當前節點的目前全部來自於不同線路的最優路徑，因為對於換乘站點，只儲存一條最優的路徑是不夠的。而在每次更新新節點的路由表...
軟體工程結對專案 地鐵出行路線規劃程式
psp2.1 personal software process stages 預計耗時 分鐘 實際耗時 分鐘 planning 計畫30 30 estimate 估計這個任務需要多少時間 6060 development 開發300 420 analysis 需求分析 包括學習新技術 3030 d...