提要——本學期評分概述
評分概覽
2020春W班評分展示，千帆競發圖、工程能力變化圖、工程能力雷達圖、曆次作業成績、學号搜尋成績等：https://www.hengyumo.cn/score-show/
助教總結
1. 目錄/班級連結
班級連結：2020春|W班 (福州大學)
總結目錄
- 目錄/班級連結
- 學期工作總結
- 自動化評測工作
- 工作改進
- 工作反思
- 啟發和建議
- the end
2. 學期工作總結
2.1 學期工作的點評資料視圖
點評數量變化分析
- 第8周和第14周沒有新的作業，是以點評較少
- 點評數量從開學開始趨勢較平穩，到中期有一個遞減，這是當時第一次團隊作業釋出，隻需要每個團隊交一篇部落格，是以點評的工作量減小了。當然文檔評審和答辯的工作也相應增加了。
-
到了團隊沖刺時達到頂峰，這是因為當時團隊沖刺，每個團隊每天都發日志，本着周老師“堅持點評、及時回報“的原則，當時一整個星期都堅持每天看完團隊的日志部落格。
到中後期，這時團隊沖刺告一段落，點評數量減少。
- 到學期末，最後一次個人總結作業，為了深刻的了解同學們的真實回報，把這次作業幾乎每篇都看了一遍，是以點評數量增多。
點評資料總覽
點評分析
- 團隊類型作業約占2/3左右，這是因為團隊作業持續時間最久，從第4周一直到第18周，也是課程的重點；
- 本學期的點評數量相比上學期仍有增加，達到了449。盡管四月份和五月份十分的忙碌。
2.3 學期工作時間分布
平均每周花在助教的點評和評分工作上的時間約6-10小時；
開發自動評測、評分展示系統、以及各種腳本工具、助教協作系統等，花去了兩個多月的時間，累計耗時300小時+，累計編碼4萬-5萬行。
2.3 工作各項參數
- 設計和釋出作業：5次
- 參與評分：12次
- 參與答辯：7次
- 直播技術分享：3次
- 程式評測與評分：5次
3. 自動化工作
Linkin雲評測系統：
初衷：
- 大四學期擔任軟體工程實踐助教
- 作業多、評分工作量大、複雜
- 既然是軟體工程課那就嘗試用軟體工程解決
- 開發一個評分、評測、可視化分析展示的平台
意義：
- 提高程式實踐類課程的評分效率
- 友善學生看到自己實時的得分，進而知道自己的學習情況
- 對微服務架構進行系統化的嘗試
特色&難點
- 采用微服務架構，服務獨立部署，易于擴充
- 采用從GitHub下載下傳倉庫的方式，相比OJ，支援對更複雜的項目進行測試
- 自動生成微服務系統的資源、字典
- 流量監控和爬蟲防護措施
- 助教線上協作評分
- 叢集監控、熔斷監測
- 對評分進行多個次元的分析與展示
- 權限設計、安全加密完善，系統安全性高
核心技術
- Spring Cloud Zuul 搭建服務網關
- Spring Cloud Eureka 實作服務注冊中心和服務發現
- Spring Cloud Feign、Ribbon實作服務通信和負載均衡
- Spring Cloud Hystry、Dashboard實作服務熔斷和服務監控
- 大量使用緩存（Redis、Ehcache）、消息隊列（Rabbit MQ）
架構
系統圖檔
服務注冊中心：
熔斷監測與叢集監控：
背景主界面：
多級權限：管理者/教師/助教
助教評分與協作：
評分可視化分析展示：
程式評測：
4. 工作改進
4.1 自我改進
- 作業規範化加強了
- 作業創新性加強了（疫情系列作業）
- 點評提高：發現問題、展現針對性
- 加強了評分限制
- 極大加強了自動化工具
- 首創直播，分享技術
4.2 承前啟後
- 繼續延續每周小結，同時制定的周小結模闆得到周老師的推薦使用
- 繼續采用自動評測評測程式，提高工作效率
- 專注每一次（線上）答辯過程
- 挖掘優秀的助教苗子，為後續課程獻力
- 專注每周的點評，持之以恒
5. 工作反思
5.1 工作不足之處
對助教團隊的管理缺乏具體的手段，應該更加強調助教的任務名額。但是這需要提前建立一個助教的考評機制，由老師來牽頭，類似于公司績效制度。
5.2 與同學們的交流
我相比同學們，隻大他們一屆；癡長一年，技術上比他們多看幾本書，是以他們的問題也多半能解答一下；
IT行業是典型的工程師思維，大家普遍會尊重技術更牛的人，是以加強自身的技術水準很重要；
此外釋出通知時盡量減少指令式的語氣，多用溫和的語氣；這一點能在同學們心中留下好一些的印象；
5.3 學期工作計劃
助教工作方面跟着課程的進度走，會提前計劃下周要做的事情；
學期計劃以開發完成各項自動化工具為前提，輔助提高課程品質；
5.4 作業點評
這學期的作業基本做到了消滅零評論，這主要得益于團隊的精誠合作，雖然這學期大家都遇到了很多的事，但是大家仍然能互相包容互相支援，這是最讓人感動的❤；
但在“及時評論”方面還有一些不足，因為作業送出普遍集中到作業截止的原因，導緻作業截止當天的作業量很大，沒有辦法當天全部點評完；
5.5 助教合作
本學期的助教合作還是比較默契的，無論是點評工作還是評分工作上。這學期和徐助教、林助教、陳助教都配合的很愉快，他們都十分的優秀。😁
6. 啟發和建議
6.1 問卷調查
6.2 建議
1. 評審表應該統一由助教設計，并單獨給每個組填寫
去年這學期時項目評審表是小組自行設計的，列印出來分發給老師同學填寫，這一方式的資料收集難度較大，需要将紙質資料轉為excel；此外讓小組自行設計評審表，也會導緻各組評分項分值設定不同的情況（比如某個小組PPT做的好，就把自己的PPT分數占比設高）；
這學期助教工作做的改進就是采用共享文檔來統一收集，這一方式使得資料的搜集更為容易，也統一了評分的标準，但是評分變成公開，影響了收集到的評分的準确性，導緻評分有一定的趨同性；
在下學期應該做相應的改進，給每個小組提供一份線上評分表，用來為其他的所有組統一評分；
2. 應該繼續加強各類技術教程，提前安排同學們學習
普遍欠缺的教程是web開發、代碼規範、github使用、IDE使用這些方面；
3. 團隊GitHub實訓的題目應該提前一到兩天通知
本學期的團隊程式設計時間相對而言太過于倉促了。
4. 組隊方式
可以嘗試采取之前我在周小結中提到的自由組隊+随機抽取的機制。自由組隊+随機抽取的方式：每個隊先招募5個人，剩下的2人随機配置設定，避免弱弱結合，比如這學期，我們班級一共13個隊，每個隊先招5人，扣去65人，剩下的（92-65）人随機的平均配置設定到各個隊伍，如果人數有剩餘，沒法保證隊伍人數一緻，就用抽簽的方式保證公平，通過這種方式減少技術實力對團隊項目進行的影響。
5. 換組繼續保持，但是要繼續細分技術保證換組的正向作用
采取主動協調換組+被動随機換組的方式來進行這學期的換組工作。其中主動協調換組是讓各小組有意向換組的同學先進行報名（每組最多一人），被動随機換組是采取随機方式，在沒有換組的組之間，根據組同技術分類+個人同技術分類的方式，來進行換組。是以在進行換組之前采取共享文檔的方式收集了班級同學的組技術分類和個人技術分類。通過這種方式可以減少換組之後的适應成本，模拟實際人員調動情況，減少同學們的抗拒。
6. 補交作業的問題
因為部落格園送出作業後還能做對應的修改，這導緻有部分同學鑽空子，先在截止前交作業，然後再慢慢修改；
這方面隻能希望部落格園能做相應的完善；因為助教沒有辦法在短期内為所有作業打完分；
7. 繼續在自動化工具這條路走下去
争取最大程度的解放助教/老師的那些繁重的工作，這樣就可以專注于課程的優化和提高了。
7. the end
最後，感謝一直勉勵我的汪老師、傅老師、周老師！感謝一起努力一起共事的其它三位助教！！
感謝鄒欣老師周筠老師背後的建構之法團隊！！！
期望福大後續軟體工程實踐會越來越好！！！
緻敬我的母校和培養我成長的軟體學院😘，期望越來越好~