評分總表
下述表格适用于前端、後端、爬蟲開發者的評分，基礎分數為50分，在此基礎上進行增減。
| 類别 | 程度 | 加減分 |
|---|---|---|
| 準時性 | 提前完成 | +0 |
| 按時完成 | ||
| 延後完成，遲交時間一天内或未延誤進度 | -2 | |
| 延後完成，遲交時間一天以上或延誤進度 | -4 | |
| 品質 | 品質較高，可讀性好，可擴充性好 | +2 |
| 品質過關或者bug極其微小 | ||
| 品質較差，有非架構設計上的功能性bug | ||
| 品質差，且修複較困難，甚至延誤項目進度 | ||
| Bonus | 協助他人完成因拖延或技術難題而未完成的工作 | |
| 完成額外的開發任務 |
PM由于工作性質較為特殊，是以不參與以上打分。PM若在實際開發階段中參與了開發，則可适用Bonus相關的規則。PM的分數将由剩下的所有同學，在團隊項目驗收結束後進行統一打分。打分模闆如下。如果該模闆不夠詳細，可進行進一步細化。
| 評價 | 分數 |
|---|---|
| 非常盡職盡責，積極性強 | +4 |
| 較為盡職盡責，比預想的好一點 | |
| 一般，隻是做了該做的事情 | |
| 不太盡職盡責，對日期和任務不敏感 | |
| 非常不盡職盡責，有些PM的本分工作甚至需要開發者來提醒 |
準時性評分
對于Alpha階段開始時所開放的issue，大家都有在Alpha階段結束時較好的完成。不過，在測試這一周，依然出現了不少需要開發的任務，這些任務先前沒有配置設定，會計入“完成額外的開發任務”的bonus中。
是以，在準時性方面，大家都沒有扣分。
品質評分
所有的額外開發任務和Bug都有issue進行記錄，對issue進行量化評分。統計4月23日~5月4日之間的issue。
| issue類别 | issue内容 | 負責人 | 備注 |
|---|---|---|---|
| 設計bug | 爬蟲：無法分析兩個老師共用同一節數的課表資訊 #84 | 杜博玮 | |
| 溝通bug | 消息隊列：修正格式 #86 | 李嘉铖、杜博玮 | |
| 後端：ddl上出現未知錯誤，傳回時間為空 #88 | 胡彬彬 | 存在截止日期為空的情況 | |
| 後端：成績查詢成績不全 #89 | 李嘉铖 | ||
| 爬蟲：消息隊列程序無法正常處理 #92 | |||
| 後端：user_login報錯 #94 | 胡彬彬、杜博玮 | 爬蟲修改錯誤傳回值後溝通不及時 | |
| 後端/爬蟲：課表重複課程 #95 | |||
| 後端/爬蟲：課表沒有13、14節課的資訊 #97 | |||
| 爬蟲：課表格式分析再度出錯 #98 | |||
| 爬蟲：Try-catch覆寫不全，對于課程中心的形式無法正确處理 #103 | |||
| 後端：兩級制GPA計算 #131 | |||
| 爬蟲：部署在後端的Chrome沒有kill幹淨 #133 | |||
| 爬蟲：課程中心頁面分析bug #140 | 截止日期存在“未顯示” |
胡彬彬的代碼bug數量最少，并且每次上交之前都會進行測試，整體代碼品質在測試階段表現較好。對于上一階段做的不夠完善的錯誤處理，在測試階段也進行了修改，目前的錯誤處理資訊已經較為完善，會給到加分。
李嘉铖的代碼bug數量不多，且都是可以原諒，不太影響功能的bug。不過，在寫代碼時還是存在一定程度的粗心和考慮不周，需要注意。
杜博玮作為爬蟲開發，bug數量确實非常多。大部分debug時間都在與爬蟲交流，或者說一個bug最終總會定位到爬蟲身上。不過這不代表其代碼本身的品質比其他開發者差，隻是這份工作的特殊性導緻bug不斷。不過這麼多的bug應當也有辦法去減少。比如：
- 建立更加完善的錯誤處理機制，覆寫更全面的try-catch，起碼保證不要有chrome沒殺掉
- 與後端溝通，最好是每一個字段都有為空串或者null的準備，預防特殊情況
- 做好錯誤局部化處理，不要因為一個錯誤導緻整個爬蟲程序癱瘓（例如issue#140，issue#98）
我認為這些都是爬蟲可以做到更好的地方。在Beta階段，在使用python的requests包進行重構的時候，雖然避免了許多記憶體上的問題，但在網絡方面的問題依然無法忽視。希望爬蟲能夠做到更好。
| 按傳回鍵會回到登入界面而不是退出程式 #54 | 喬玺華 | ||
| 空教室查詢頁面無法下拉 #58 | |||
| 登入頁面錯誤處理bug #62 | 張藝璇 | ||
| 首頁設定功能在退出程式後重新進入又變成課表 #66 | |||
| 成績查詢頁面缺少夏季成績 #98 | 單彥博 |
前端總體來說，bug較少，可能是因為使用了較為成熟的架構和模闆，但存在一些疏忽的bug。
相對而言，單彥博出的bug更少，且擔任了前端code review的職責，在PM不熟悉前端代碼的情況下，充當了一個3人組内的PM角色，是以會把加分給到單彥博。
Bonus評分
下面是額外開發任務的評分參考。完全按照issue數量來定開發加分不太合适，因為每個issue的任務量不同。如果是任務量較少但可歸為一類的任務，會統一計算。
| 開發任務 | 相關issue | |
|---|---|---|
| 課表界面美化 | 課表美化 #67 課表顯示細節中，對于隻有一節課的課程，不應顯示n-n節 #87 | |
| 人性化改動 | 自定義首頁界面增加确定按鈕 #57 自定義首頁點選确認後應當自動傳回 #79 | |
| 人性化改動2 | 空教室查詢美化 #68 DDL界面增加選項，設定已完成的内容不顯示 #93 | |
| 版本更新功能 | 版本更新檢測功能 #69 | |
| 安全性改善 | 使用AES算法對傳輸的“學号”和“姓名”進行加密 #83 |
| 多爬蟲适配 | 後端：user_login支援爬蟲的多線程爬取 #107 | |
| 後端：消息隊列去重、支援爬蟲的改動 #108 | ||
| 爬蟲：支援多線程和消息隊列互動 #109 | ||
| GPA計算細化 | 後端/爬蟲：修改GPA算法以适應五級評分制，爬取課程評價資訊 #111 | |
| 版本更新 | 後端：增加版本更新功能适配 #141 | |
| 後端：使用AES算法對“密碼”和“學号”進行加密 #112 後端：能夠處理爬蟲發送的DELETE請求，并預先和資料庫密碼、消息隊列進行檢查 #114 | ||
| 爬蟲：修改并統一解密算法 #113 爬蟲：遇到“使用者名或密碼錯誤”時，告知前端删除該使用者資訊 #115 | ||
| 摒棄Chrome | 爬蟲：重構使用者登入檢查和擷取基本資訊 #142 |
最終評分
折算權重時，前端3人共享150分權重，後端3人共享150分權重。
因為要求不能出現重分，且分數必須為整數，是以如果出現重分，會優先根據代碼品質、額外開發issue數量來決定誰的分數更高。
最終分數将等PM分數投票出來後，七人共享350分權重。
| 姓名 | 品質分 | 總分 | ||
|---|---|---|---|---|
| 54 | ||||
| 52 | ||||
| 6 | 58 | |||
| 8 | 56 |
PM分數投票，權重均分53.33，截圖如下：
