Cesar競賽平臺——軟工3課程總結
軟體51 謝運帷 2015013185
經過一學期競賽平臺專案的實踐，我對於軟體過程有了更清晰的認識。我們小組從一起討論我們競賽平臺的需求，到我們設計資料庫，選擇專案使用什麼樣的框架，採用什麼樣的結構，再到我們建立起後端邏輯，完成前端頁面，我們經歷了一個個困難又將它們一個個跨了過去。總體還是很享受這個過程，只是囿於我們的時間實在太少，我個人從期中佈置這個作業下來，先是忙於應付雙學位4門課的考試，再到後來一直有計網1、2的大作業介入進來，我們真正能投入到軟工上的時間真的沒有多少了。
一、Cesar競賽平臺的完成情況
首先我來介紹一下我們競賽平臺的完成情況。我們大致完成了一下的功能點：
- 學生、主辦方兩種使用者的註冊、登入
- 兩種使用者的個人資訊檢視和編輯
- 建立一個比賽，填寫比賽的基本資訊（如名稱、描述、報名時間、參賽時間、封面、附件等等）
- 編輯一個比賽的報名過程：如組隊賽所需的資訊，人數等等
- 學生可以檢視釋出的比賽的列表
- 學生報名比賽：這裡支援組隊賽和個人賽的模式，組隊賽設計了搜尋使用者和邀請隊友的環節
6.1 填寫隊伍資訊
6.2 填寫個人資訊
6.3 搜尋、邀請隊友 - 競賽資訊主頁：所有遊客可以通過這個頁面檢視競賽的所有資訊，這裡支援了更細節的功能點
7.1 檢視競賽描述並下載附件
7.2 檢視競賽的公告
7.3 檢視競賽的階段，下載階段的賽題，為自己的隊伍提交成果
7.4 檢視競賽階段的排行榜 - 主辦方管理自己的競賽的介面：主辦方可以在這個頁面內進行競賽的管理，細節功能點如下
8.1 主辦方檢視所有報名的隊伍
8.2 主辦方稽核隊伍的報名
8.3 主辦方通過多種條件搜尋參賽隊伍
8.4 主辦方新增、編輯公告
8.5 主辦方新增、編輯一個比賽階段
8.6 主辦方階段管理：在一個階段中，給一個隊伍的成果進行評分
8.7 主辦方階段管理：匯出成表格，下載當前隊伍的評分狀況；匯入一個表格，快速地給所有的參賽隊伍進行評分 - 簡單的網站管理員介面：檢視一個比賽的資訊，稽核比賽的狀態
- 統一的許可權管理：區分我們系統的使用者（遊客、學生、主辦方）
二、學習收穫
大概我們完成的功能就是這些，基本涵蓋了一個競賽所需的基本流程，不過也就是僅僅涵蓋了最基本的功能，沒有什麼額外的功能。我個人看待這個專案的想法不是說要有多少的功能，而是我們整體的架構要組織的比較好，學習最多的新知識。我還是將這個專案作為一個作業來做，希望通過這個專案學到新的東西就好了——我和石耕源負責專案的前端，所以我們選擇了之前沒接觸過的Vue框架，瞭解真實的前端專案是一個什麼樣的工作流程。通過本次專案的鍛鍊，我們基本瞭解Vue.js的基礎語法和功能，如何通過vue-resources和後端通訊，如何使用element-ui元件庫美化我們的介面。
如果單說我們前端的完成情況的話，還是比較不錯的。我們主要的問題是在前後端的對接上，之前敘述的每一個功能點，我們都需要付出和搭建前端相同的時間去找到對應的後端介面、修復後端介面的bug、調整前後端通訊的欄位……這些主要都是因為我們每個人對應這樣複雜的軟體工程專案的認識不足，沒有從一開始就組織好程式碼的結構、維護前後端介面的文件。我們到最後才認識到程式碼可讀性和文件的重要性，不過已經為時已晚。
我也看到其他組有不同的合作形式：1.一人擔任產品經理，分析迭代目標和維護文件，組織其餘程式碼手的工作，2.兩人負責前端，兩人負責後端，一週進行一次集中開發……可惜我們各自都比較忙，很難找到一個共同的時間進行一起總結和除錯。我們基本是各兩人負責前後端，主要是同一部分的兩人進行技術交流，討論技術的難點。這就導致了我們的前後端有很多地方不能“對準”的問題，造成了額外的時間消耗。如果我們從一開始就有例行組會去維護介面文件的話，可能會更好一些。
三、個人感受以及建議～
本學期的軟工專案我給我們小組的完成情況大概可以給80分，對於我自己的工作情況大概可以給90分。之前專案一直當慣了組長，這次專案想做個安靜的組員= =。不過我們小組的組長（負責後端）組織的真的不是很好，我們前端的工作基本靠自己想，自覺做。
這學期作業真的好多……這個軟工專案更是完全不講道理，這個整個專案真的太大了，我完全不知道我往這個專案裡投入的時間能給我課程的評價帶來多少收益（=^=我好絕望），在這個專案裡學到的新技術也很有限（不少都是小學期後端和前端學過的東西）。說實話，我不喜歡做這個耗時間又學不到新技術的軟工專案。另一方面，這個專案的複雜性決定了能不能抱到大腿組長是整個專案成功失敗的關鍵= =…但是大腿就那麼多還喜歡抱團…而且，我發現這個專案基本都是採用前後端分離的模式，所以一旦組內另一個人的工作沒做好，就很會影響自己的進度…
感謝助教看完這麼長的課程總結～評分的時候手下留情啊:)……