Alpha階段項目展示

項目	内容
班級：北航2020春軟體工程	部落格園班級部落格
作業：Alpha階段項目展示	強制轉會與項目展示
産品釋出位址	Visual Lab Online

目錄

• 團隊簡介
• 軟體工程
  • 目标與預期
  • 需求分析
  • 分工協作
  • 項目管理
  • 品質管理
  • 使用者量與使用者評價
  • 資料分析
• 項目實際進展
• 成員貢獻
• 特色功能
  • 特色功能一——代碼檔案雲存儲，随時随地可程式設計。
  • 特色功能二——你的下一個IDE，何必是IDE。
  • 特色功能三——不僅稱心順手，更有無限可能。
• 使用者回報
• 總結

頭像	姓名&個人部落格連結	主要工作介紹	職位
	向WL	初步原型設計、項目管理與維護，同時負責前端編輯器和後端語言服務	PM、編輯器開發、測試
	李PX	後端多層級伺服器和前端terminal的開發，同時負責前後端接口的設計與實作	前後端開發、測試
韓WZ	後端多層級伺服器的負責人，同時維護docker和各項服務，在釋出階段負責運維	後端開發、測試
孫XD	前端IDE頁面的設計和開發，主要負責檔案樹、整體布局等界面和與編輯器的對接	前端開發、測試
韓FJ	前端IDE頁面的設計和開發，主要負責檔案樹、建構設定等側邊欄的設計與建構
萬ZF	前端首頁的設計和開發，負責登入注冊、查找與展示項目、進入項目等功能

團隊項目的目标，預期的典型使用者，預期的功能描述，預期的使用者數量在哪裡？

• 項目目标：做出一款對程式設計新手更易用的cloud IDE
• 典型使用者：
  • 不關心程式編譯運作環境、隻想快速寫少量代碼的使用者（如刷算法題的學生）
  • 難以了解工程、編譯、運作等概念和配置，想專心學習程式設計本身的學生（如大一C語言學生）
  • 希望在多平台同步程式設計、且希望服務更加便捷的使用者（如不友善FQ、希望使用北航雲盤存儲的使用者）
• 預期的功能描述：功能規格說明書
• 預期的使用者數量：團隊項目選擇

對于項目的目标使用者是一般學生的項目， 你們如何找到學生做需求分析？他們給你什麼樣的回報？

我們團隊有部分成員曾擔任計組/C語言等課程助教。我們注意到在教學過程中，大一大二剛剛接觸專業課的學生對于新語言要求的環境往往比較迷惑，尤其是經常浪費大量時間在C/C++系的編譯、運作等設定（GCC路徑、工程與單檔案等）上。在教學生如何正确使用CodeBlocks/Dev C++等IDE時，學生往往對複雜的概念和操作步驟表示疑惑和不滿。是以我們希望打造一款概念簡單、産品輕量化、但核心功能完善的線上編輯器及運作環境。

團隊的成員如何分工協作的？有什麼經驗教訓？

我們将整個軟體分為前後端兩部分。其中在前端中，編輯器的開發是相對獨立的闆塊，可以和其他網頁構件差別開來。此外，我們的web應用大緻分為首頁（入口頁）和IDE頁兩個頁面。是以，我們的分工如下：

• 前端
  • 前端首頁：萬ZF
  • 前端IDE頁：孫XD、韓FJ
  • 前端編輯器：向WL
• 後端
  • 後端：韓WZ
  • 後端 & 前後端接口：李PX

然而事實證明，這樣的分法有以下兩個問題：

1. 當任務進度與計劃不一緻時（如某人提前做完了計劃任務），分工應當有一定調整（如提前做完的同學去幫助進度落後的同學）
2. 分工相同的同學（如前端頁面的三位同學）效率有待提高，避免溝通不及時 / 陷入等待 / 多人同時做一件事 導緻時間浪費

為建立更有效的溝通，前端同學們建立了自己的小微信群，進而實作更快、更直接的溝通。

團隊是如何進行項目管理的？

我們在GitHub上建立了Organization，将代碼分為前端、後端、編輯器三個倉庫，分别維護自己的代碼和Issues。其中編輯器部分在scrum過程中會周期性地合并入前端部分中，在前端的master分支釋出最新的前端版本。

我們的多人合作主要靠Git Branch & Merge (PR)實作，如負責首頁的同學在Homepage_Signin分支，負責IDE的同學在IDE分支，最終合并到master分支。

我們的任務清單、問題記錄等均通過issues進行記錄，有BUG、potential BUG、need enhancement等标簽對issue進行标記，友善日後檢視和作為提醒。同時我們使用這個工具自動生成燃盡圖。

為更好地控制任務進度、制定更有效的計劃，我們按照團隊任務拆解中的做法将整個沖刺階段分為了三個子階段，每個子階段設立一個Milestone，有一份燃盡圖。這樣我們對于接下來的四五天的工作計劃将更加動态且有針對性，使得任務進度控制更加真實有效。

團隊如何平衡 時間/品質/資源 争取如期完成任務的？

由于我們的軟體為web應用且邏輯分支有限，且各個子產品之間較為獨立、定位bug容易，是以我們在前端舍棄了進行完整單元測試&覆寫，而是先追求進度、再根據團隊成員模拟使用者的各種使用操作進行端到端的測試。在一開始bug/未完成好的feature點确實較多，但在最後一周的穩定釋出階段我們對所有問題進行了整理并統一優化、修改。是以可以說我們的政策為：先追求進度後補上品質。

測試用例數目，代碼覆寫率數目。運作測試用例得到代碼覆寫率的視訊錄像。

我們在後端部分使用Java實作了部分功能，對此後端同學進行了單元測試：

後端單元測試 @ Bilibili

此外，後端内的容器服務，使用的是nodejs完成的，是以這裡使用istanbul+mocha工具進行單元測試以及覆寫率統計：

後端nodejs單元測試 @ cnblogs

然而在前端和其他部分，我們的代碼包括了Javascript、vue、Python等多個語言平台，難以組織起全面的單元測試。且我們認為大部分代碼的邏輯分支有限，可以通過最終模拟使用者使用進行端到端的測試将其覆寫。

其中使用者登入注冊的邏輯分支較多，前端同學使用jest進行了單元測試：

前端登入單元測試 @ Bilibili

代碼規範在哪裡？

我們的項目涵蓋了Javascript、vue、Java、Python、shell、Dockerfile等多種語言和系統，團隊并非在統一平台上工作，是以我們沒有統一顯式的代碼規範，但我們在commit代碼前會使用編輯器的代碼格式化功能将代碼進行整理。如使用VSCode寫Javascript代碼，右鍵 format document将會使用VSCode内置的格式化器和預設代碼規範進行格式化。

齊全的文檔在哪裡？

我們的項目中存在大量“接口”。幸運的是，大部分接口的兩端的對接工作為同一名同學完成，是以一旦接口有變，修改是簡單且不容易出錯的。對于前後端之間的接口，由于其涉及到的人員較多、涉及到的引用較廣，我們在 易文檔撰寫了較為完善的HTTP接口文檔，對請求參數、響應參數等進行了規範和說明：

團隊的産品如何滿足了使用者的需求？要看到目标使用者使用産品的過程和評價。

我們通過提供一個全線上、免配置、開箱即用的開發環境，進而讓使用者隻需專注于代碼編寫，而無需考慮複雜的環境配置與搭建。

事先定義的軟體下載下傳量達到了麼？為什麼沒有達到？

截止到5月7号，共有57名使用者注冊了我們的系統，累計建立了100+個項目，但并沒有達到預期。

關于原因分析，我們總結有以下幾點

1. 釋出推廣的目标人群存在問題，我們軟體的目标人群是初學程式設計的同學，而我們初期的主要推廣人群基本都是大二以上的同學，這些人群基本上已有自己稱手的IDE，是以可能并沒有十足的興趣參與到我們的軟體使用中來。
2. 受測試期間得到的伺服器負載能力的影響，我們采取了逐漸推廣的方案，也導緻最終軟體的使用人數沒有達到預期。

所有的項目都會收集到使用者的資料，請問你們對這類資料做了什麼樣的分析，這些分析如何驗證或推翻了原來的假設？這些資料如何幫助項目改進軟體工程的品質？

• 前端部分總燃盡圖
• 後端部分總燃盡圖
• 編輯器部分總燃盡圖
• 關于燃盡圖
  • 我們認為在項目的前中期，燃盡圖确實有效地反映了項目的真實狀态和進展
  • 然而在項目後期（約最後5天），燃盡圖沒有真實反應（醜化了）項目的實際進展：
    • 對于後端部分，最後幾天沒有大的開發任務和改動，主要工作是小bug的修複和小改進，即穩定和準備傳遞階段，上述的很多小改動小更新沒有被算在issue裡，且改動不多，是以燃盡圖上隻是open幾個issue意思一下。
    • 對于前端部分，最後幾天功能和樣式修改較為頻繁和劇烈，很多臨時發現的bug或臨時做出的優化沒有被及時記錄，沒有完全記錄在issue中；且工作較多、沒有精力随時開啟、關閉issue，是以燃盡圖上不僅有遺漏、還有一定延遲。
• Alpha階段最終釋出的功能
  • 首頁
    • 登入與注冊
    • Notebook管理（列出已有項目、搜尋已有項目、進入已有項目）
    • 賬戶管理（重置使用者名、重置密碼）
  • IDE頁
    • 側邊欄
      • 檔案管理器（檢視檔案樹、右鍵菜單中建立檔案/檔案夾、重命名、複制、剪切、粘貼）
      • 建構設定（選擇需要編譯/運作的源檔案、編譯、運作、編譯并運作）
      • 上傳與下載下傳（從本地上傳檔案到雲端、打包下載下傳目前項目到本地）
    • 終端
      • 使用者可操控的全功能遠端終端
      • 在終端中編譯并運作
    • 菜單欄
      • 檔案（建立檔案等）
      • 編輯（剪切複制粘貼、查找替換等）
      • 代碼操作（跳轉括号、選擇括号、折疊展開等）
      • 運作（編譯與運作）
      • 視圖（切換小地圖顯示、切換行号顯示），幫助（問題回報、使用指南）
    • 多标簽編輯器
      • 編輯功能
      • 語言服務（Python & C/C++）
        • 代碼高亮
        • 代碼補全
        • 代碼格式化
        • 代碼跳轉
        • 插入代碼片段
      • 多标簽頁
• 釋出位置：以網站的形式，在釋出Visual Lab Online
• 使用者回報截屏

（注：代碼行數統計工具為

git log

和

cloc

，僅統計有效代碼行，為粗略值）

（注：團隊貢獻分總分為 50 * 6 = 300）

名字	角色	團隊貢獻分	具體的, 可衡量的, 可驗證的貢獻
	PM&Dev&Test	53	- 17次會議記錄，釋出聲明&功能規格&項目展示3篇部落格 - 主持了22次會議 - 1280行代碼行 @ vLab-Editor - 找出了16個bug，修複了8個bug
	Dev&Test	57	- 技術規格&項目選擇2篇部落格 - 發起了2次推廣 - 前後端API接口1篇技術文檔 - 1820行代碼行 @ vLab-Frontend & vLab-Backend - 找出了12個bug，修複了6個bug
		55	- 測試報告1篇部落格 - 2480行代碼行 @ vLab-Backend - 找出了10個bug，修複了4個bug
		45	- 團隊貢獻分1篇部落格 - 2080行代碼行 @ vLab-Frontend - 找出了7個bug，修複了13個bug
		44	- 任務拆解1篇部落格 - 1650行代碼行 @ vLab-Frontend - 找出了8個bug，修複了9個bug
		46	- 事後分析1篇部落格 - 1900行代碼行 @ vLab-Frontend - 找出了6個bug，修複了5個bug

所做軟體最有特色的功能是什麼，請着重介紹一下。活的使用者如何從你的軟體中獲益的，請現場展示。

現在建立一個Notebook，你寫的每一個字都在Notebook中被時時刻刻自動儲存到雲端。無論是筆記本、台式PC、Mac或是iPad，随時随地登陸Visual Lab Online都可以繼續之前的工作。

之前寫了的代碼忘記儲存到哪兒了？想重新跑一下之前寫過的代碼？維護一個代碼模版倉庫？Visual Lab Online都可以輕而易舉的做到。代碼不丢失，更改即儲存，點選就取得。

在Visual Lab Online中，不需要任何配置就可享用大部分IDE的功能——檔案樹、編譯運作、終端、代碼高亮、錯誤檢查、代碼跳轉、定義與引用、語義級代碼補全、變量與函數提示、代碼格式化……了不起的內建開發環境，以線上的形态更先進地完整呈現。

這一切，無需使用者配置，隻需建立一個Python/C++ Notebook，點選即用，越用越好用，随時打開随時都能用。

在Visual Lab Online中，我們繼承了來自Monaco Editor的優秀編輯操作，讓使用者獲得媲美VSCode的良好編輯體驗。不僅如此，我們還對部分功能進行了重新定義，讓寫代碼這件事，變成效率翻倍、大快人心的大好事。

除此之外，我們還調研了Python/C++代碼中使用者經常寫到的代碼片段，加入到了我們的代碼補全中。隻需敲幾下鍵盤，就能快速獲得一大段你想要的代碼。

除此之外，我們提供的全功能遠端終端更能支援使用者玩出無限可能。在docker容器内，使用者可以安裝第三方軟體、第三方庫、下載下傳頭檔案……随心定制自己的程式設計環境，而不影響到其他使用者。

團隊從使用者那裡得到了什麼回報，有什麼樣的bug？這是預料之中的還是沒想到的？

使用者回報了一個菜單欄-建立檔案失敗的bug，和一個terminal最下端顯示不全的bug，其中前者是沒想到的，後者是意料之中的已知bug（但暫時無法解決）。

得到使用者回報後我們對bug迅速進行了修複。

使用者回報貼連結

整個團隊在Alpha階段學到了什麼，對軟體工程的教育，對這個具體的課程有什麼批評建議？Beta階段有什麼大體計劃？

• 我們意識到了：
  • 應該在計劃時對任務的工作量有更準确的估計，且工作量≠難度
  • 應該給測試、穩定和傳遞預留出更多的時間，盡量進行較為完整的單元測試
  • 應該在産品的定位和閱聽人上做進一步調研和分析，進一步明确産品的最終目标，進一步細化産品需要傳遞的功能
  • 理想的使用者量目标和現實的有限伺服器資源存在沖突，應該在制定目标時考慮資源有限的情況，制定更切合實際的使用者量目标
• 對軟體工程教育的建議：

  • 應當更加靈活。如類似本團隊産品的項目，由多個系統組成且十分複雜，全部進行完整的單元測試是不現實的。且本項目工作量較大、内容較多，在一開始就對3周沖刺進行完整計劃是不現實的&意義不大的，是以我們采取了折中的手段——将alpha分為三個子階段、擁有三個燃盡圖。

    像這樣的，學生沒有100%按照課程要求進行工程實踐的，應當對其做法的利弊進行分析，在評分時考慮實際情況和實際做法的科學性。

  • 應當在更多問題上提供較為合理的解決方案。我們注意到在團隊貢獻分、團隊任務拆解等等許多作業中，教學團隊給出的引導一般是前人的作業作為樣例、和鄒欣老師的部落格/《建構之法》中的文本。然而在鄒欣老師的部落格/書中，很多問題沒有一個明确的回答，而是以“你們團隊又應該怎樣做呢？”的問題結束，且在前人樣例中的做法也各不相同。這就導緻最終我們的做法的科學性和合理性沒有保障，基本取決于團隊的主觀意願。我們希望在教學過程中能夠給出一些科學的方案（軟體工程是否是一門科學？）供學生讨論選擇适合自己團隊的。
• Beta階段的計劃：
  • 優化後端容器服務，将一個Notebook對應一個docker改變成其他兩種方案，進而優化伺服器資源使用
  • 加入雲盤、github支援
  • 加入java語言支援
  • 有意願向網頁插件等方向發展（如算法練習oj上的插件，支援完整的編輯器體驗）等