一個實作部門與學生智能比對的小程式。
【軟體工程實踐 · 結隊項目】 第二次作業
Part 0 · 簡 要 目 錄
- Part 1 · 項 目 信 息
- Part 2 · 數 據 生 成
- Part 3 · 匹 配 算 法
- Part 4 · 結 果 分 析
- Part 5 · 結 對 規 範
- Part 6 · 結 對 過 程、感 受
開 發 人 員
開 發 人 員 一：鄭浩晖
031502442
開 發 人 員 二：劉晨瑤
031502522
項 目 相 關
項 目 描 述：一個實作部門與學生智能比對的小程式。
項 目 地 址：https://github.com/TheSkyFucker/DepartmentSelector
代 碼 統 計：
- 核 心 代 碼：2200行，去除自動生成文檔後約1200行。
- 測 試 代 碼：450行。
README 預 覽：
源 代 碼 管 理：
（0）最 終 數 據
數 據 文 件 地 址：傳 送 鍊 接
最 終 數 據 預 覽：
（1）輸 入 信 息 整 理
部 門 信 息 整 理
Department
| 參 數 | 類 型 | 範 圍 | 簡 述 |
|---|---|---|---|
| | | 部門編号（唯一） |
| | | 學生上限 |
| | | 活動時間 |
| | | 特點标簽（必有） |
學 生 信 息 整 理
Student
| | | 學生編号（唯一） |
| | | 空閑時段 |
| | | 部門意願（優先級遞減） |
| | | 興趣标簽 |
（2）考 慮 因 素 整 理
學 生 部 分
模 仿 實 際 格 式 生 成 學 号：
按 課 切 割 的 空 閑 時 段 池：8:20 ~ 10:00, 8:20 ~ 10:00, 10:20 ~ 12:00, 14:00 ~ 15:40, 15:50 ~ 17:30, 19:00 ~ 20:40, 20:50 ~ 22:30
傾 向 時 間 不 沖 突 的 部 門：按照顯示場景确實要優先考慮。
傾 向 标 簽 更 匹 配 的 部 門：個體可能會有比較大的差異，但從普遍的角度來說這是趨勢。
可 能 選 擇 時 間 沖 突 部 門：即意願強烈，故模拟學生時沒有一棒打死，而是加上了一個負權，仍有被投志願的可能。
部 門 部 分：
按 真 實 情 況 近 似 比 率：
活 動 時 間 具 有 波 動 性：長度以及開始時間等具有一定程度的波動。
（3）生 成 流 程 設 計
（0）總 覽
算 法 概 括：“質 量 感 人（高）， 數 量 也 感 人（低）”
總 架 構 圖
（1）分 配 原 則（質 量 先 行）
第 一 原 則 · 時 間 沒 有 沖 突
- “解 釋”：如果和正常活動時間沖突，即便比對了最後也會因多次曠活動而被淘汰；
第 二 原 則 · 學 生 意 願 優 先
- “解 釋”：即使最後是沒中選的結果也不會讓學生比對到不在其意願清單内的部門。
第 三 原 則 · 部 門 意 願 優 先：
- “解 釋”：學生投遞志願後，具體比對結果有部門主導。
- “按 輪 次 先 投 顯 得”：如果剩餘人數不超過部門人數限制，則全部中選。
- “同 輪 次 擇 優 錄 取”：當人數太多時，部門根據對每個候選學生的評定擇優錄取。
第 四 原 則 · 拉 低 富 裕 差 距：
- “解 釋”：配置設定中，已中選部門多的同學 相比 已中選部門少的同學，應有一定的劣勢。
- “中 得 越 多 越 難 繼 續 中”：把中選部門數量作為學生評定的一個因素。
（2）學 生 評 定
核 心 公 式："排 序 權 值" = "标 簽 匹 配" X "中 選 價 值"
中 選 價 值：1 / ( 已中選部門數量 + 1 )
标 簽 匹 配：該學生和該部門共有的标簽數量。
（3）淘 汰 算 法
一 輪 淘 汰 · 時 間 沖 突 的 學 生
二 輪 淘 汰 · 按 學 生 評 定 擇 優
（4）特 殊 考 量
學 生 中 選 多 個 部 門
- “要 求”：部門之間的活動時間必須不沖突。
- “設 計”：會把 已中選的部門的活動時間 從每一輪 中選的學生的空閑時間 中扣除。
輸 入 信 息 存 在 疏 忽
- “要 求”：雖然約定好了 “時間段無交”，“标簽不重複” 等原則，但由于資料并非共同開發的團隊提供，作為外來的資料，我們讨論後覺得有理由也有必要做一定的處理。
- “設 計”：私有化成員，在提供的對外接口完成 “自動合并有交時段”，“自動去重标簽” 等。
- “示 例：自 動 合 并 空 閑 時 間 代 碼”
（0）分 析 聲 明
測 試 原 則 一：不測極端資料，所有學生空餘時間、标簽爆表然後全部中選，不具有測試意義。
測 試 原 則 二：不測小資料，小資料下生成算法波動大不穩定，不具有測試意義。
分 析 方 向 一：品質。
分 析 方 向 二：數量。
（1）學 生 中 選 率
結 果 不出所料的比對率不高。
分 析 原 因 一：時間不沖突優先原則首當其沖，比對率較低；
分 析 原 因 二：為了求品質，中選部門時，學生的空閑時間被部門活動時間壓縮，再比對率較低。
（2）部 門 中 選 率
結 果：相對理想，300學生20部門時，我們生成的資料沒人的部門大概保持在 10% 左右。
（3）中 選 學 生 滿 意 度
結 果：較好，符合預期。
原 因：因為我們的考量中時間不沖突占較大比重，且保證了 中選的多個部門時間不沖突，自然我們的分析中也會把時間不沖突的權重加大。
（4）波 動 來 源
分 析 原 因 一 · 标 簽 池 的 大 小
- 分析加測試發現，标簽池調大時如果測試資料量不變大，則算法效果會差不少。
- 因為标簽比對可能性降低，而和時間不沖突疊加在一起，出現沒有部門适合的機率變大。
分 析 原 因 二 · 空 閑 時 段 池 的 大 小
- 理由同上一個一樣，池子越大，出現适合的部門的機率會降低。
（1）規 範 文 檔
CodingStandard.md
（2）部 分 規 範 示 例
“函 數 帶 文 檔”、“命 名 符 合 規 範”
“先 寫 測 試 在 寫 代 碼”
“适 當 注 釋”、“函 數 專 注 于 一 件 事”
（1）結 對 過 程
階 段 一 · 準 備：商定初次讨論時間，再次之前各自認真閱讀作業需求，為讨論做準備工作。
階 段 二 · 讨 論：圍繞作業需求，提出自己的疑惑點、想法，确立項目核心算法的初步設想。
階 段 三 · 設 計：共同設計架構圖、流程圖。
階 段 四 · 實 現：國慶期間采取共享螢幕結對程式設計，邊實作邊讨論。
階 段 五 · 測 試：生成一些資料進行測試、讨論和分析。
（2）結 對 感 受
提 高 效 率：
- 感覺效率提高了不少，即便再小心有時候還是會漏掉一些東西，然後過後才注意到，受到更大的影響。
- 結對中不少問題都是當即被對友發現，把損失降到了最低。
思 路 更 廣：
- 個人總是容易陷入思維盲區，獨自程式設計的狀态總是會有一定的波動，然後或多或少的留下一些品質較差的代碼。
- 兩個人同時思考領航員時不時提出 “是否有必要性” 等等的設問，一步步朝更好的方向前進。
（3）結 對 建 議
先 寫 測 試！：
- 結對中我們依舊是堅持貫徹 “先寫測試”，雖然一開始可能會有寫出來的東西沒怎麼被用上的感覺。
- 當項目快收尾時設計了一些改動，測試直接把改動造成的問題暴露了出來，快速的就能摸着單元測試找到那一塊地方出現了問題，感覺非常的棒，瞬間會覺得哪怕隻為了這一次也值了。
代 碼 管 理！：
- 結對中每個小階段的完成雙方都有必要提醒一下對方進行一次
commit
- 對整個整個項目的脈絡的拿捏也會随着源碼管理的進行而不斷變得清晰。
End.