前言
Beta階段第7次會議在5月12日22:00由PM在大運村一公寓三層召開, 時長30min。
任務分配
| 姓名 | 今日任務 | 明日任務 | 困難 |
|---|---|---|---|
| 周博聞 | 修復修改密碼問題#54 添加主頁公告欄 #57（調整樣式） |
修復修改密碼問題#54 | |
| 周國傑 | 控制台接口單元測試#51 | 2200116 數據處理腳本#59 | |
| 樊子康 | markdown后端路由及控制器#38 markdown后端處理腳本#39 |
markdown前端用戶選擇界面#40 | |
| 殷劉霄羽 | 2200116實驗模板 #60 | D01實驗內容梳理 #61 | |
| 何雨峰 | 2200116實驗模板 #60 | D01實驗內容梳理 #61 | |
| 王尖兵 | 移動端報告頁 - 收藏夾#46 | 移動端報告頁 - 收藏夾#46 | |
| 楊帥 | 控制台接口單元測試#51 | 控制台接口單元測試#51 |
燃盡圖
會議照片
代碼簽入記錄
項目困難
修改密碼的問題仍然沒有找到具體原因，考慮暫時擱置。
與助教談話（5.11）
關於交付件的驗收標准
"但某些后端的任務沒有定義可衡量的交付內容，基本都是通過：人工驗證該接口/后端模塊功能實現了，就算是交付了"
如果人工驗證的話，可否給出驗證的流程？比如某個功能執行了某個操作，給出了怎樣的預期輸出
我們認為這個比較靠譜，將在任務完成的差不多時補全一下這部分任務的驗收工作。
可以考慮后端盡量使用單元測試進行驗收，而前端可以進行功能方面的驗收。
注：在寫了一些測試后我們發現，對於后端一些難以用單元測試驗證的功能，在不復雜的情況下仍需要采用人工測試的方式，例如上個階段中關於上傳實驗報告的部分，目前並沒有找到比人工測試更好的辦法……
關於降低腳本開發門檻
這個部分原先是PM在Alpha階段收尾時開的一個腦洞，即做成拖拽式的腳本編寫，但團隊成員包括PM自己都認為這個短時間內做不完（甚至可以單開一個軟工項目）所以目前擱置了。
原來是這樣，建議博客補全
不過我們認為本階段的markdown功能對於實驗模板編寫門檻的降低是起到了一定作用的，但python腳本這里目前沒有好的解決辦法。
關於新成員工作
@新成員 我看你已經做了一個頁面設計，還有重構，正在添加主頁公告欄。新技術上手了嗎？
逐漸上手了。
你和另一個同學都做了 #42 #43 #57三個任務，講講經過？比如是均分任務還是結對編程？
PM：感覺都有，比如主頁這邊改的時候基本是A改然后B來做復審以及提供一些意見。然后主頁公告欄這里就有點均分任務的意思，A加好html部分然后B調樣式。
新同學開發有什么困難嗎？
困難當然就是要適應這個項目的框架。實際上前段改的的東西也不算太多，主要是處理一些細節，要把這個項目的前段全部閱讀一遍然后改。
除此之外困難也出現在熟悉開發流程方面，我們靠qq遠程桌面交流並解決了一些操作問題。
這個時候就可以進行結對編程了。
關於規范commit記錄
感覺你們的commit可以規范一下。簡單可以，但風格有很多種不太行。以及像有多個commit處理一個功能的情況，可以使用
git rebase -i合並多個commit
我們可以在之后統一一下commit的格式，比如統一使用動名詞組的形式。對於一些注釋性的內容可以放在comment里。
（不知道comment是一個github的功能還是git本身自帶的功能，還需要繼續研究）
關於單元測試
我看你們之前提到了要搞單元測試，講講單元測試方面的進展？
現在單元測試寫了一半了，感覺開好頭之后就要輕松一些，主要是不好上手。
有留文檔嗎？比如測試計划、進度之類的。
沒有，這部分就是開會的時候討論匯報的。
下一屆的人接手項目之后怎么上手單元測試之類的東西有考慮過嗎？
這部分我們計划出一篇技術博客的，關於單元測試方面，但現在坑還沒有踩完。（還在坑里沒完全爬出來
預計單元測試還要做多久？
這個得看最終計划覆蓋多少代碼吧，控制台部分應該明后天可以全部覆蓋測試完成。
“假如項目一開始就有詳盡的單元測試，對於之后接手的同學也比較友好。” 我覺得你們可能需要多寫一點注釋和文檔來體現這個友好。
引申：關於Gamma計划的討論
（接以上的話）
我們最近討論了一下Gamma階段的任務，因為感覺其實這個網站功能也就目前這樣了，所以在考慮下個階段主要目標是提升一下工程的質量，包括文檔、注釋還有代碼規范啥的。以及一些編碼不好的地方修改，比如之前在代碼里寫死了很多配置方面的內容。
我覺得如果你們把完善項目作為目標的話，要設計好怎么檢驗，最終怎么評判。
這個我們也有所考慮，主要是需要從比如 注釋量 這種指標以及與之前文檔的對比方面來考慮。以及一些統一的配置文件和使用說明等等。
感覺這部分是如果結果不是很清晰，很容易給人一種在划水的感覺。
是的。