一路青春，感謝有你——『近取Key』 - Beta 項目展示

項目與團隊亮點

一、團隊成員與分工簡介

成員組成與分工

本團隊由 6 名成員組成，其中有 3 名 PM，2 名后端開發人員與 4 名前端開發人員，由於組內成員數量有限，因此所有 PM 均需同時兼領開發任務。

團隊整體采用前后端分離的開發模式，雙方主要基於 API 文檔進行交互與協作；PM 則需要對項目整體進度、核心功能實現、開發流程規范等方面進行把控，確保項目能夠有條不紊地順利進行。

管理模式

由於今年課程組統一要求基於 Gitlab 進行敏捷開發，因此本項目在 beta 階段繼續沿用石墨文檔 + GitLab issues 的方式進行共同管理。二者可以做到相輔相成，優劣互補，從而盡可能實現科學且富有人性化的管理模式。

在石墨文檔上，團隊會將下一階段需要完成的各類任務進行統一的梳理，並將相應的結果記錄到文檔中，同時計算生成相應的、具有特色的燃盡圖。具體特色分析請見第二部分：項目與團隊總結。

在 GitLab 上，團隊會基於石墨文檔中的任務內容，將其中與代碼編寫相關的任務以 issue 的形式予以發布，便於團隊成員在開發過程中進行及時查看。在開發的不同階段，團隊也設置了相應的 milestone，從而將 issue 進行歸類整理。

在項目開發過程中，我們實施完全的前后端分離策略，下圖分別為前后端的 issue 截圖。

beta階段改進

在alpha階段中，為了查看的方便，本團隊通過 wiki 的形式進行 api 文檔的發布與共享；但是 wiki 並不支持查看每次更新的日志記錄。因此，為了及時掌握各 api 在開發過程中的更新變動情況，同時也為了將文檔與代碼部分徹底解耦合，在 beta 階段本團隊在前后端分離的基礎上，進一步將文檔(documentation)也作為一個單獨的 project 進行管理，從而保證各部分的獨立性與靈活性。

溝通對接

在整個開發過程中，本團隊同樣繼續貫徹線下討論為主，線上交流為輔的溝通策略，具體表現為本團隊的每次 Scrum Meeting 均為線下進行，總計共進行了 10 次線下討論/集體開發會議，其中有明確會議記錄的有 7 次。

事實證明，與線上討論相比，線下集體交流無疑要更為高效，成員之間也更易達成一致，形成默契，培養友誼。

特別地，由於現場討論主要是在教室進行，因此，在最后沖刺階段的 Scrum Meeting 中，我們依然繼續保留 alpha 階段的特色——“kanban法”，充分因地制宜，直接在黑板上列舉當前需要解決的主要 issue，從而充分發揮線下開發的優勢，使得團隊的每一個人都能對當前的任務進度一目了然。

beta階段改進

但同時，與 alpha 階段相比，beta階段在強調團隊協作之外，對於個人的開發也給予了充分的自由度和發揮空間，這主要基於以下原因：

1. beta 階段與一些課程的烤漆重合，且不同同學選課內容不同，因此同步協作難度有所上升；
2. beta 階段的新增功能相互之間較為獨立，各成員分工明確，無需像 alpha 那樣對核心難點進行集體攻關；
3. 各成員在 alpha 階段的開發后，對於軟件已有了一個全面的了解，同時對於自己負責的任務也具備了高度的責任感和創新靈感，需要給予他們更多的自由空間。

二、典型用戶場景

本部分重點針對 Beta 階段的預期目標以及開發過程中新增功能的實現情況分別進行分析：

預期目標

預期目標	功能描述	預期用戶場景
引導性教程設計	實現用戶初次登錄的步驟化教程引導，便於用戶上手	初次使用本軟件的用戶
視頻及H5宣發	制作宣傳用視頻及H5，在眾多社交平台進行宣傳	對A4紙背單詞法不太了解的用戶，初次接觸本軟件的用戶
分享社區實現	設計並實現用戶社區，以便分享詞圖	多個用戶想要協同背單詞，或者某用戶想要獲取現成詞圖
加詞、單詞出現的位置優化	將加詞的默認位置分散。在復習時詞圖以過渡動畫形式移動。	某些用戶傾向於使用單詞自動彈出位置。詞圖較大、單詞位置較分散時需要動畫過渡。
自定義詞圖背景	用戶可以選擇自己喜歡的帶有含義的背景圖片作為詞圖背景	意義明確的詞圖可以幫助用戶更充分地發揮空間聯想能力。
單詞測試功能	在用戶復習測試時，通過輸入拼寫等方式豐富測試模塊	用戶需要檢驗自己對單詞的記憶程度，以及是否能正確拼寫。
用戶頭像上傳	支持用戶自定義頭像	默認頭像好丑，使用用戶心儀的頭像可以提升用戶幸福感
平板適配	升級用戶在平板端的使用體驗，包括排版適配，動作監聽等	用戶想在平板上通過瀏覽器使用本軟件
統計信息豐富	增加更豐富的統計信息，包括詞書背誦進度、整體詞庫記憶狀態等
單詞推薦算法升級	增加更多的單詞推薦方式	不同用戶對背誦單詞的關聯度要求不同。有的傾向於隨機，有的傾向於使用詞根詞綴、近反義詞等關聯方式

新增功能

預期目標	功能描述	預期用戶場景
用戶默認個人設置	在用戶設置界面，用戶可以設置默認詞書、推薦方式、發音類型、單詞數量、復習模式等，方便用戶后續操作。	某用戶長期背誦一本次數，每次新建詞圖重新選擇較為不便
Http轉Https	通信通過Https加密，進一步提升安全性
字體、主頁、我的詞圖界面美化	將全局字體和主頁進行ui美化，將我的詞圖頁面進行重構並添加過渡動畫。	用戶使用時，ui的而美觀程度將大幅度影響使用感
社區中用戶狀態瀏覽	在社區中，不僅可以查看詞圖，還可以查看分享詞圖的用戶的部分狀態信息	某用戶發現用戶A的詞圖很對自己的口味，於是詳細瀏覽該用戶的詞圖

用戶場景的滿足情況

用戶	用戶需求回顧	已滿足	Alpha階段結束后暫未滿足	Beta階段結束后暫未滿足
田旭堯	1. 普及A4紙背單詞法的理念 2. 讓其明確感受到本軟件和其他背詞軟件的獨特之處 3. 讓其感受到此單詞軟件沒有缺失作為背單詞軟件的基本功能	1、2、3	3（待添加對單詞的離散型測試功能）	無
田昶舜	1. 普及A4紙背單詞法的理念 2. 本軟件能吸引其注意力，讓其背單詞時能夠集中精神，實現長久記憶 3. 背詞形式有趣，能夠讓用戶擁有“換腦子”的體驗 4. 支持考研詞匯的背誦 5. 和朋友一起協同背單詞	1、2、3、4	5（待添加社區功能）	無
田昶禹	1. 普及A4紙背單詞法的理念 2. 本軟件能讓其集中精力長時間背單詞且少產生疲憊之感 3.本軟件能有有效的統計機制，時刻提醒用戶進行復習，時刻反應用戶對單詞的掌握狀態，提高用戶對已背單詞的掌握程度	1、2、3	3（待添加更豐富的統計信息）	無
田永曉	1. 擁有海量詞庫，支持特殊詞書要求的背誦 2. 本軟件能讓其集中精力長時間背單詞且少產生疲憊之感 3.本軟件能有有效的統計機制，時刻提醒用戶進行復習，時刻反應用戶對單詞的掌握狀態，提高用戶對已背單詞的掌握程度。 4. 本軟件具有強大的自定義功能，讓用戶可以自由組成詞圖	2、3、4	1（待添加更多單詞推薦選項）、4（待添加用戶自定義加入單詞的功能）	無

綜合來看，本軟件已覆蓋了用戶個人使用時的主要功能，且建立了較完善的用戶社區，從而達到 Beta 階段的功能要求標准。

用戶評價

根據收集到的用戶反饋，用戶普遍認為該軟件具有特色，並且使用方式新穎，具備一定的趣味性，達到背單詞需求，功能相較於alpha階段有明顯的豐富，尤其是社區功能、單詞測試功能的添加比較有亮點。目前的主要問題集中在請求速度（如詞圖背景api的加載速度）較慢，另外，由於本軟件功能較多，初次上手仍存在一定的困難。

用戶反饋詳見第二部分：項目與團隊總結。

三、殺手級功能

Beta 階段結束后，本項目已經形成了完善的核心系統功能架構：

其中，Beta 階段新增的重要的殺手級功能有：

• 單詞鍵入復習

  

• 自定義加詞

  

• 自定義背景

  

• 分享社區

  

具體功能描述見下文功能介紹部分。

競品對比

針對 Beta 階段新增的功能，我們將本軟件和當前市場眾多背單詞app，以及近日在 B 站剛剛嶄露頭角的A4紙背單詞法小程序進行競品對比。競品對比圖如下：

功能	百詞斬	扇貝單詞	墨墨背單詞	A4紙背詞法小程序	近取key（Beta）
選擇詞書	✅	✅	✅	✅	✅
顯示列表背單詞	✅	✅	✅	⛔	✅
多種單詞發音	✅	✅	✅	⛔	✅
例句發音	✅	✅	⛔	⛔	✅
額外詞典	⛔	✅	✅	⛔	✅
艾賓浩斯遺忘曲線	⛔	⛔	✅	⛔	✅
打卡日歷	✅	✅	✅	✅	✅
各單詞掌握情況	✅	✅	⛔	⛔	✅
詞圖相關功能	⛔	⛔	⛔	✅（較簡陋）	✅
分享與社區	✅	✅	✅	⛔	✅
更改頭像	✅	✅	✅	⛔	✅
單詞復習	✅	✅	✅	⛔	✅
單詞鍵入	⛔	⛔	⛔	⛔	✅

競品主要缺失詞圖相關、單詞鍵入相關等功能。主要原因為競品大多基於手機端app實現，而移動端的小屏幕不足以將可編輯詞圖的優勢發揮出來。另外，手機端打字也較為不便。

本產品充分利用了PC端的大屏優勢和鍵盤優勢，實現了高自定義度的詞圖編輯功能和帶有鍵入的詞圖復習功能，並且基於詞圖對社區功能、fork等用戶間交互操作進行了實現。

四、產品推廣與用戶數據

目前，團隊使用H5宣傳冊、B站宣傳視頻等多種宣傳方式進行了推介，取得良好的宣傳效果。

H5宣傳冊

H5宣傳冊目前累計瀏覽量為1600次，總瀏覽人數957人，總分享量39次。詳細數據如下：

每日具體數據如下：

B站宣傳視頻

我們於6月17日下午16時在b站發布宣傳視頻，截至6月19日上午12時，視頻播放量已達到996次，達到了良好的宣傳效果：

視頻流量分析如下圖所示：

累積用戶

我們以累計注冊量為累計用戶，在某天查看、修改、新建、復習一次詞圖才被視為該日的日活用戶。目前軟件累計用戶量已達 253人，較 alpha 階段增加了約150人，平均日活用戶量為 26，具體數據如下：

我們通過線下采訪和線上用戶反饋模塊收集兩種方式對用戶的反饋進行了收集，詳細內容請見第二部分：項目與團隊總結。

五、軟件工程質量

文檔整理

后端根據預期功能進行了較為充分的數據庫預設計，通過兩個 issue 3 4、以及 ER 圖 定下了數據庫的基本功能；對於單詞基本信息以及其他信息，我們分別使用不同分支進行開發，並對於涉及數據庫更新的部分撰寫了詳細的設計文檔。

在 alpha 階段，本項目使用 Gitlab 的 wiki 對 API 文檔進行了完整的書寫、實現及整理。另外，前后端人員通過固定的 issue 區對 API 進行改動匯報。

而在 beta 階段，為了對 api 文檔的修改記錄實現動態追蹤，本項目將文檔部分作為一個單獨的 project 進行獨立出來，並利用 GItLab 的 commits 與 diff 功能了解相關 api 的更新細節，避免了不必要的溝通成本。

代碼規范

前后端均對於代碼風格、內容、命名、錯誤碼和返回值進行了規范，詳見第二部分。

Gitlab 使用

前端和后端在開發過程中都使用 issues 對每位成員的工作任務和進度進行關注，並使用 milestone 對所有 issues 進行歸類，展現每一階段的完成進度。目前 Beta 階段的全部里程碑均以 100% 完成。

另外，我們通過給 commit 信息添加 issue 鏈接實現將 commit 與相應的 issue 進行關聯，並利用 markdown 自帶的 checkbox 對部分重要的 issue 的具體進展情況進行實時追蹤，從而更清楚地反應對某一 issue 的完成進度和每一 commit 完成的工作。

測試情況

由於本項目的運行對數據庫具有極高的要求，情況較為特殊，正常地測試需要使用自定義的生產數據庫進行，單元測試實現較為困難。但我們仍舊通過制作接口、構造數據等方式進行了部分單元測試，覆蓋率達到 69%。

沒有達到較高覆蓋率的原因有三：

1. 使用雙重校驗，每一個 API 都使用解析 token 和解析用戶兩步進行，保證了用戶隱私的安全性，但同時難以構造測試用例對於能夠通過 token 解析但是通不過用戶解析的場景，故每一個 API 都無法測試這一點；
2. 部分 API 使用與其他 API 類似的結構，僅更改了部分影響內容（如修改字體、修改大小等），對於此類問題由於時間限制等原因沒有進行完備的測試；
3. 對於登陸和注銷有關權限 API，進行了較為完備的場景測試，沒有進行單元測試。

本項目在前端和后端都對 CI/CD 環境進行了配置並且成功運行。由於后端單元測試直接部署在服務端，CI/CD 需配置 django 和 mysql 等一系列軟件、故最終沒有采用，但在本地提交時會自動進行單元測試；前端實現了 CI/CD 自動部署。主要用途為對項目進行持續集成，並持續測試能否成功打包，為后期向服務器的部署提供了方便。

除了單元測試和 CI/CD，本項目還使用其他方法進行了測試：

• 手動構造測試：進行了大量的模擬用戶操作的構造測試。

• 壓力測試：對於服務器的各項負載能力進行了全面的分析和壓力測試。

具體測試細節和結果詳見測試報告。

項目與團隊總結

一、項目管理

溝通對接、分工協作的展示部分見項目與團隊亮點一。

成員簡介與個人博客地址

成員簡介和個人博客地址可見本團隊的團隊介紹博客。

團隊分工

本部分內容基本與 alpha 階段一致，並在其基礎上加入 beta 階段的具體任務說明。

詳細的分工及工作內容如下所示：

崗位	成員	具體工作
PM	tcy, my, zyh	1. 組織開展例會，明確任務分工 2. 把控整體進度，完成博客撰寫
前端開發測試	zyh, xpy, zjs, xmy	1. 完善項目主頁、詞圖管理、統計信息等主要頁面 2. 實現用戶社區、單詞測試等功能 3. 完成前端 API 文檔 4. 實現前端頁面與組件之間跳轉邏輯 5. 前端生產環境部署
后端開發測試	tcy, my	1. 提升系統安全性、響應速度 2. 完善后端數據庫 ORM 模型 3. 完善並增加前端所需要的各 API，包括詞圖等社區推薦算法、統計信息計算、詞圖克隆等 4. 覆蓋進行后端壓力測試、單元測試

管理模式

本項目采用 石墨文檔 + Gitlab issues 的方式進行共同管理。

與 Gitlab 相比，石墨的優勢主要表現為以下幾點：

1. 可以為每個任務的實際工作量進行定量評估，而不是僅僅基於該任務的完成時間進行測算，這在客觀上可以更好地衡量開發人員實際投入的時間與精力。
2. 由於 Gitlab 本身不支持直接生成燃盡圖，或者生成的燃盡圖並不足夠真實准確，因此基於石墨文檔有助於更方便地生成實際任務量對應的燃盡圖。
3. 考慮到開發人員在開發過程中還存在其他的課業壓力，以及某些任務在制定初期可能比較粗糙，不夠明確，因此需要在開發過程中對任務的分配進行進一步的細化調整，這一點也使得石墨文檔更具優勢。

項目分支

在項目開發過程中，我們實施完全的前后端分離策略，即前端與后端分別創建自己的 project，彼此之間僅通過協商好的 API 接口進行交互。這表現在項目開發上，即為前后端的提交無需再進行額外的 merge，從而保證了代碼與環境的相互獨立。

由於詞圖與單詞詳細信息數據體量較大，考慮到目前的系統負載能力，我們選擇犧牲組件之間的耦合度，來減少和后端之間的通訊次數，從而最大程度為系統減負。

另一方面，對於后端而言，由於其總體工作大致可分為數據解析爬取與 Django 框架搭建部署兩部分，因此我們分別對其創建了相應分支，從而保證生產環境下代碼的干凈整潔。

燃盡圖

通過石墨文檔計算得出的整個開發周期的燃盡圖如下所示：

注意到，與其他組的燃盡圖相比，本組的燃盡圖具有以下特點：

1. 剩余任務量/預計任務量的單位並非為 issue 個數，而是對任務進行了更細致的難度評定，從而更科學地對其進行量化
2. 項目預計進度並非一條直線，而是充分考慮到實際情況，不同任務給出了不同的預計完成時間
3. 基於 iFrame 框架實現，可交互，便於實時查看和更新當前最新進度

團隊貢獻分分配

本團隊在貢獻分分配上，充分考慮了不同成員領取的任務量與任務難度差異，並對其進行了系統的量化。此外，本團隊還引入了互評機制與獎勵機制，從而最大程度激發每一位團隊成員的積極性，力求客觀全面公正。

最終計算得到的各成員貢獻分如下表所示：

成員	實際任務量	任務貢獻分	團隊互評得分	簽到得分	貢獻獎勵分	最終得分	beta 具體貢獻
tcy	201	32	9.5	9	3	53	撰寫博客文檔，負責大部分 API 以及社區統計推薦算法，詞圖克隆等功能后端實現，組織開展多次線下集體開發會議
zyh	187	31	9.5	9	2	51	撰寫博客文檔，負責前端統籌開發，單詞復習測試功能實現，參與組織多次線下集體開發會議
my	189	31	9.17	7.5	1	49	撰寫博客文檔，負責后端單元測試等任務，完善部分API接口與單詞推薦算法
xpy	171	28	9.17	9	2	48	負責詞圖中畫布相關功能與統計信息頁面的完善。適配與字體美化等
zjs	191	31	9.5	9	2	52	負責詞圖管理頁面UI重構、用戶社區等版塊設計與實現
xmy	171	28	8.67	8.5	2	47	負責主頁、教程引導實現，制作H5與宣傳視頻

二、用戶場景

典型用戶

用戶信息	用戶情況
姓名	田旭堯
身份	某校非英語專業大二學生
使用動機	英語不太好，想多背一些單詞沖刺四六級，但是沒有什么動力
典型場景1	在宿舍突然想背單詞，打開 APP 使用一些背詞功能
典型場景2	在食堂，飯太燙閑着無聊沒事干，背幾個單詞
用戶偏好	幾乎不背單詞，或偶爾零碎地背單詞（非受眾）
用戶痛點	不知道怎么復習/背單詞，想要短時高收入
預期目標	由於非主要受眾，因此對此類用戶的預期目標為：1. 普及A4紙背單詞法的理念 2. 讓其明確感受到本軟件和其他背詞軟件的獨特之處 3. 讓其感受到此單詞軟件沒有缺失作為背單詞軟件的基本功能

用戶信息	用戶情況
姓名	田昶舜
身份	某校考研黨，英語單詞量不高，需要大量提升
使用動機	想要在半年里把考研單詞記熟，每天抽出一定時間專門背單詞
典型場景1	復習數一數二膩了，背背單詞學學英語換換腦子
典型場景2	突然被某篇雞湯激勵到，立誓背完考研單詞，然后背了五分鍾
用戶偏好	偶爾會專門背記單詞，主要時間不會用太多，但會用系統化的時間專門記憶單詞
用戶痛點	單詞量較大，碎片化背單詞過於低效，且容易注意力不集中、記憶不長久
預期目標	1. 普及A4紙背單詞法的理念 2. 本軟件能吸引其注意力，讓其背單詞時能夠集中精神，實現長久記憶 3. 背詞形式有趣，能夠讓用戶擁有“換腦子”的體驗 4. 支持考研詞匯的背誦

用戶信息	用戶情況
姓名	田昶禹
身份	可憐高中生，高考近在眼前
使用動機	高考英語單詞必須得全部背過呀
典型場景	每周末在家抽出3~4h專門背單詞
用戶偏好	使用整塊的時間系統化背單詞，且對每個單詞的掌握程度要求高
用戶痛點	碎片化的背單詞法不適用於一直坐着學習的高考黨
預期目標	1. 普及A4紙背單詞法的理念 2. 本軟件能讓其集中精力長時間背單詞且少產生疲憊之感 3. 本軟件能有有效的統計機制，時刻提醒用戶進行復習，時刻反應用戶對單詞的掌握狀態，提高用戶對已背單詞的掌握程度

用戶信息	用戶情況
姓名	田永曉
身份	某校英語專業或出鍋留學生
使用動機	有大量背單詞的需求，常啃紅寶書等詞書，普通的碎片化記憶模式 APP 不適合了
典型場景1	某一天要背好多單詞，不想背着一大摞書去圖書館，硬啃，普通的背單詞軟件過於碎片化，滿足不了需求
典型場景2	看了個英文電影，想把電影里整理出來的單詞加入候選背單詞列表中
用戶偏好	系統化背單詞，即專門抽出時間閱讀書籍、影視並記憶有關單詞
用戶痛點	紙質書籍重且較不方便、沒有交互；大量學習中產生的零散單詞除了手寫記錄難以集中背誦，且無法自定義位置；希望能提供基於詞根詞綴、近反義詞的推薦背誦詞
預期目標	1. 擁有海量詞庫，支持特殊詞書要求的背誦 2. 本軟件能讓其集中精力長時間背單詞且少產生疲憊之感 3.本軟件能有有效的統計機制，時刻提醒用戶進行復習，時刻反應用戶對單詞的掌握狀態，提高用戶對已背單詞的掌握程度 4. 本軟件具有強大的自定義功能，讓用戶可以自由組成詞圖

項目發布功能

對於Beta 階段已發布的功能，僅拷貝發布文檔的重要功能概述，其余具體功能實現情況及展示詳見發布文檔。

新功能介紹

『UI界面更新』

首先，前端對軟件字體進行了美化設置，同級字體采用一致的美觀字體。

另外，前端針對我的詞圖界面進行了着重ui優化，包括修改整體布局、過度動畫，新增極簡模式適應用戶的不同需求。

教程引導

對於首次使用本軟件的用戶，我們提供了引導性教程，一步一步指導用戶完成第一張詞圖的建立。教程引導覆蓋：

• 新建詞圖
• 編輯詞圖（加詞，工具欄）
• 測試詞圖

社區

功能特性詳述

新增社區功能。用戶可以在社區中查看其他用戶公開的已完成詞圖，查看某用戶的詳細信息（包括點贊數量、宏觀背詞狀態等）。

針對感興趣的詞圖，用戶可以進入預覽，查看詞圖的全貌和自己對該詞圖中單詞的掌握狀態。

對於喜歡的詞圖，用戶可以將其克隆到自己的詞圖中，並且對齊進行加詞或編輯。

用戶在社區中的操作用例圖如下：

個人設置

在個人設置中，用戶可以上傳大小不超過100KB的頭像，並可以對新建詞圖、測試詞圖模塊的默認設置進行設定。

統計信息

統計信息界面新增了用戶背誦的當前詞書的背詞進度（比例），以及用戶對已經背誦的單詞的總體狀態。

用戶訪問統計信息時的時序圖如下：

自定義搜索加詞

在編輯詞圖時，用戶可以通過搜索加入自己想要自定義加入的單詞。被選中的單詞講自動添加到待背誦列表的首位。

用戶在新建、編輯詞圖時的時序圖如下：

復習單詞測試

PC端擁有鍵盤的優越性，讓用戶可以通過敲入要復習的單詞來強化記憶，同時系統會根據用戶的敲入狀態更新用戶對本單詞的記憶狀態。

如果敲入單詞正確，按下回車后將顯示單詞的含義，再次按下回車將自動跳轉到下一個單詞。

如果敲入錯誤，按下回車后系統將對錯誤的字母進行提示（方框標紅），用戶可以通過backspace進行順滑的刪除修改。如果用戶忘記單詞的拼寫，可以點擊提示，將展示單詞的。

側邊欄將實時顯示已復習單詞的記憶狀態。

用戶對某一單詞的記憶狀態機如下：

詞圖背景圖及復位

新增詞圖設置背景圖片功能。用戶可以通過工具欄選擇心儀的背景圖片，並在此之上完成詞圖的構建。每次重新進入編輯頁面，背景圖庫將更新。

對於由於zoom和拖拽導致的詞圖位置偏移，用戶可以點擊工具欄的復位按鈕回歸默認視覺中心位置。

刪除單詞

用戶可以選中詞圖中已有的單詞，點擊工具欄中的刪除按鈕移除單詞。

單詞出現位置優化

在用戶點擊加入詞圖后，單詞在詞圖中出現的位置將以當前視覺中心為圓心進行擴散，隨機分布在畫布較合適的位置上。

視覺中心移動動畫

在復習時，有些單詞之間的距離較遠，需要進行視覺中心的移動。我們采用速度適中的動畫效果進行視覺中心的切換。

發布位置：

目前本軟件已支持直接通過域名訪問！

域名：jqkey.xyz

另外，本項目同時配備H5宣傳手冊及宣傳視頻。

H5宣傳冊

B站宣傳視頻

三、用戶日活

用戶日活數據

見項目與團隊亮點四。

用戶反饋

我們通過線下采訪和線上用戶反饋模塊收集兩種方式對用戶的反饋進行了收集。

線下采訪部分截圖：

線上收集數據：

由於時間較短，暫時沒有收到用戶反饋數據。

功能性問題

下面對兩種途徑獲得的功能性建議和 bug 進行匯總。

Alpha 階段用戶反饋

用戶反饋（功能）	問題原因	是否解決
不認識的詞需要點擊兩邊，操作冗余	設計時結合扇貝單詞的機制有意如此實現，但從用戶反饋來看不符合大多數用戶的使用習慣。	已修正用戶對單詞掌握程度的邏輯
iPad 平板無法拖拽縮放詞圖	目前 Alpha 版本成品對平板的適應不夠完全	否
復習時單詞默認在中間出現	由於單詞有可能出現在畫布內，因此暫時將這種出現方式作為默認方式	單詞隨機位置出現，減少重合概率
不能刪除單詞	Alpha 版本暫未實現該功能	是
不能修改頭像	Alpha 版本暫未實現該功能	是
不能自定義背景圖片	Alpha 版本暫未實現該功能	是
新手教程不夠友好	目前教程作為獨立頁面存在，但用戶希望能和使用界面進行融合，手把手教學	實現了更友好的教程
沒有測試模塊	Alpha 版本暫未實現該功能	是
部分 UI 為中文，部分為英文，不夠統一	在對多模塊進行分別設計時沒有對 UI 的語言進行規定	將前端語言風格進行了統一

Beta 階段用戶反饋

用戶反饋（功能）	問題原因	解決方法
工具欄功能不夠明顯	缺少工具欄的引導	暫時考慮用戶自行探索，也可添加鼠標移上去顯示功能

bug 反饋

下面對兩種途徑獲得的 bug 反饋進行匯總：

用戶反饋（功能）	問題原因	解決辦法
iPad 平板無法拖拽縮放詞圖，側邊欄無法顯示	目前 Alpha 版本成品對平板的適應不夠完全	爭取增加畫布對平板分辨率和交互方式的適配性。

綜合來看，目前用戶反饋的 bug 較少，大多集中在前端的效果及多設備的適配方面，沒有影響用戶正常使用的嚴重功能性 bug 出現。

四、特色功能

殺手級功能、與競品的對比見項目與團隊亮點三。

預期目標與團隊自我評價見項目與團隊亮點二。

五、軟件工程質量

文檔、測試見項目與團隊亮點五；經驗教訓見項目與團隊總結六。

分支規范

對於單詞基本數據的解析和導入，我們使用了獨立分支 parse_mdx 進行開發，使用公開的 ecdict 數據，並在 issue 中進行了闡明。

對於詞根詞綴、同近義詞、詞書的解析和導入，我們使用另一個獨立分支 parse_wordbook 進行開發，通過 issue 6 13 進行了數據的獲取、解析和導入，並針對每一需要更新數據庫結構的部分都寫了設計文檔，如詞根詞綴、同近義詞，其中描述了設計目標、文件格式、數據庫設計、實現過程（如手動修改了哪些值，或如何進行實現）、以及 TO-DO 表示可改進之處。

代碼規范

后端開發過程對一下幾點實現進行了規范：

• 進行了代碼的命名規范：不進行簡寫、使用下划線命名法。

• 進行了代碼的內容規范：API 傳入時先進行錯誤處理、異常判斷；且對於需要返回的異常情況進行捕獲並返回錯誤碼，對於無需返回的異常情況則不進行處理，允許拋出不捕獲的異常；等等。

• 對於錯誤碼的類別，進行了規范。

• 對於返回值，成功和失敗分別進行了規范。

前端在代碼開發前對組件、函數的命名進行了規范：

• Vue 組件命名采用 kebab-case 規范，遵循 W3C 規范中的自定義組件名及 Vue 官方風格指南。
• 組件內部變量、方法命名采用駝峰命名規范。

注釋與運行

前端對頁面、組件進行了一一對應的結構組織，代碼結構清晰。另外，在與畫布相關的復雜組件中，前端使用規格和文字對函數進行了注釋。在其余功能單一的組件中缺少部分注釋。

前端可以在配置好相關開發環境的新機器上輕松運行，如要與后端進行交互，則只需修改配置文件即可。

npm install
npm run serve

后端主要工作在於對 API 的實現，由於 API 文檔的完備性，后端具體實現邏輯簡單，故代碼中注釋較少，API 文檔已能夠清晰地展現后端代碼結構。

在新機器上，后端正常編譯是可以通過的；但數據庫不會自動導入，這是因為我們使用自己的方式對於數據庫進行了分批導入與更新。如要獲得完整數據庫，需要將 parse_wordbook 分支中 main.py 里的注釋逐個解掉並運行，具備可行性，但暫且沒有相應文檔。

單元測試與CI/CD

前端

在 beta 階段中，為方便前端項目的實時部署與動態迭代，前端基於 scp 實現了相應的CI/CD功能。

后端

在 beta 階段中，后端進行了較為完備的單元測試，測試覆蓋率達到70%。

而之所以沒能達到更高覆蓋率，其原因主要有如下三點：

1. 出於安全性考慮，每個 api 均使用雙重校驗，分為解析 token 和解析用戶兩步進行，從而最大程度保證了用戶隱私與后端數據的安全性，但同時難以構造測試用例專門針對能夠通過 token 解析但是通不過用戶解析的場景，故每一個 API 測試都無法對這雙重驗證的第二重實現覆蓋；
2. 部分 API 使用與其他 API 類似的結構，僅更改了部分影響內容（如修改字體、修改大小等），對於此類問題由於時間限制等原因沒有進行完備的測試；
3. 對於登陸和注銷有關權限 API，主要進行了較為完備的場景測試，沒有進行單元測試。

六、反思與展望

Beta 反思

伴隨着烤漆的鍾聲與一門門課大作業 ddl 的結束，軟工 beta 階段的開發也就此終於落下帷幕。

如果把 alpha 階段比作是在一片白茫茫荒漠中摸索出一條大致的路來，那么 beta 階段就是要努力讓這條路變得更寬更廣，讓更多的人能夠走上這條我們開創的路，並能夠收獲更美麗的風景。

在 beta 階段的開發中，我們在 alpha 里積累的所有優良傳統（比如全線下meeting，kanban法沖刺等）都得到了很好的保留；同時，更令人欣慰的，是團隊中的每一個人都最終找到了自己合適的定位，在這樣的一個項目里做着自己感興趣的那部分工作，發揮自己的長處，幾乎是不求回報地想要把自己的那份工作做到最好，做到極致。

這一切，作為PM的我(tcy)，全程都看在了眼里。我記得，小樹不斷地將前端的 UI 界面進行反復優化與重構，只求為用戶提供最絲滑的使用體驗；我記得，Mokoghost為了實現詞圖中單詞移動的動態效果，親自手寫了最底層的動畫播放邏輯；我記得，潛行的螞蟻對於主頁、教程的反復打磨，以及在宣發時的不遺余力；我還記得，圓那超強的執行力以及不怕苦不怕累的擔當和責任感；還有Potassium對於核心算法的實現與數據的爬取做出的無可替代的貢獻……

類似的故事還有很多很多，多到足以讓我堅定不移地相信，我們團隊里的任何一個人，放到外面的任何一個地方，都能做到獨當一面，都能一人撐起一個甚至多個部門，都能成為未來IT行業的超級精英。

回到軟件本身上來，可以說，beta 版本的『近取Key』已經幾乎實現了我們在 alpha 開發伊始所能設想到的全部的功能，『記憶宮殿』、『A4紙背單詞』這些最核心的創意與邏輯均已得到了淋漓盡致地展現，此外還增加了諸如自定義加詞、智能推薦等等意料之外的功能。但是，這還不能說它已經足夠完美了，只能說這是我們6個人在短短2個月時間內，在無數烤漆裹挾下，在極有限的資源加持下，所能交出的一份最好的答卷。

但是，這絕不是這個軟件本身所能達到的最完美的形態。

無論是從軟件本身的可維護性、安全性、跨平台兼容性，還是從用戶體驗視角下使用的流暢性、健壯性、交互友好性，抑或是從商業視角下的盈利能力、宣發能力，我們和它都還有很長很長的一段路要走；甚至也許，這條由我們親自開辟的路，永遠也不會有所謂的盡頭。

更遠的未來

目前，為了更好地證明我們所做出的這個成果的價值，我們已經為其申請了全國大學生創新創業年會創新訓練項目，並已成功入選。

這之后，雖然軟工這門課的使命已經結束了，但由這個因所種下的果還將在未來很長的一段時間內持續長久地存在着。這並不是因為它能夠給我們帶來物質上的什么回報，而是因為在他的背后，承載的是我們整個團隊大學三年中最寶貴的一份回憶，以及回憶之中所凝結的青春與汗水。

這才是軟工這門課真正的價值，才是大學所應有的意義。