案例分析作業——VS和VS Code

項目	內容
這個作業屬於哪個課程	2021春季軟件工程（羅傑 任健）
這個作業的要求在哪里	案例分析作業
我在這個課程的目標是	認真完成課程要求並提高相應能力
這個作業在哪個具體方面幫助我實現目標	學習已有軟件的經驗

前言

微軟公司有兩個代碼編輯器：Visual Studio和VS Code。雖然都是很牛的代碼編輯器，但二者在許多方面都有所不同。本文將對這兩者做一些探討。

第一部分 調研與評測

VS Code部分

1.安裝

VS Code簡直是傻瓜式安裝，安裝界面一路無腦下一步即可，附加任務也沒有什么令人摸不着頭腦的選項，如下圖：

2.功能使用

初始進入時界面為英文，為方便起見，可在擴展中心安裝插件以變更語言為中文，這里就直接使用中文的VS Code進行演示。

可以看到界面很簡單。默認情況下其工具欄在頂部，同時一些常用功能在左側以圖標形式給出。進入時如果沒有打開文件、工作區等，則會進入歡迎界面。

下面新建一個文件，並寫一段最簡單的C代碼，但是在書寫過程中代碼並沒有高亮顯示。原因是在沒有保存的情況下，其默認為txt文本。現在我們將其保存為.c文件，如下圖：

可以看到代碼立馬就有了高亮。除此之外，VS Code還在右下角貼心地提示你是否安裝C語言的推薦擴展以便運行.c文件。

當打開或是建立一個工作區/文件夾后，默認情況下左側會多出其樹形結構以方便進行文件的切換。同時如果代碼過長，右側還提供縮略圖以便快速定位，如下圖：

在各項環境配置完成后，我們可以設斷點並啟動調試，比如下圖即是調試運行一段C#代碼：

可以看到其控制台顯示在下方，上方出現了各種調試操作，非常方便。

3.Bug發現

借這個機會體驗一下SCP的寫作方式。

為方便對嚴重性進行評級，在此給出划分標准(全文適用)：

Bug影響	分級
對程序正常使用有致命的影響，或是存在安全漏洞	Keter
對程序正常使用有一定影響，或是有較大影響但不經常出現，或是對用戶體驗有較大影響	Euclid
對程序正常使用影響較小，對用戶體驗無太大影響	Safe

作為微軟的軟件，又經過了長時間的更新與修復，VS Code的Bug可以說是非常之少。但是如果本着“吹毛求疵”的精神，還是能發現以下Bug：

• Bug編號：Bug-1
• Bug等級：Safe
• 測試環境：Windows 10操作系統，Visual Studio Code 1.54.3
• Bug描述：對於結構比較混亂的代碼仍提供塊隱藏的服務，但是不能隱藏到正確的位置。這里的結構混亂指的是不按照通常的方法來寫代碼，例如建議換行的地方不換行，建議縮進的地方不縮進等。
• 詳情：

例如對於如下js代碼：

/*! http://responsiveslides.com v1.54 by @viljamis */
(function(c,I,B){c.fn.responsiveSlides=function(l){var a=c.extend({auto:!0,speed:500,timeout:4E3,pager:!1,nav:!1,random:!1,pause:!1,pauseControls:!0,prevText:"Previous",nextText:"Next",maxwidth:"",navContainer:"",manualControls:"",namespace:"rslides",before:c.noop,after:c.noop},l);return this.each(function(){B++;var f=c(this),s,r,t,m,p,q,n=0,e=f.children(),C=e.size(),h=parseFloat(a.speed),D=parseFloat(a.timeout),u=parseFloat(a.maxwidth),g=a.namespace,d=g+B,E=g+"_nav "+d+"_nav",v=g+"_here",j=d+"_on",
w=d+"_s",k=c("<ul class='"+g+"_tabs "+d+"_tabs' />"),x={"float":"left",position:"relative",opacity:1,zIndex:2},y={"float":"none",position:"absolute",opacity:0,zIndex:1},F=function(){var b=(document.body||document.documentElement).style,a="transition";if("string"===typeof b[a])return!0;s=["Moz","Webkit","Khtml","O","ms"];var a=a.charAt(0).toUpperCase()+a.substr(1),c;for(c=0;c<s.length;c++)if("string"===typeof b[s[c]+a])return!0;return!1}(),z=function(b){a.before(b);F?(e.removeClass(j).css(y).eq(b).addClass(j).css(x),
n=b,setTimeout(function(){a.after(b)},h)):e.stop().fadeOut(h,function(){c(this).removeClass(j).css(y).css("opacity",1)}).eq(b).fadeIn(h,function(){c(this).addClass(j).css(x);a.after(b);n=b})};a.random&&(e.sort(function(){return Math.round(Math.random())-0.5}),f.empty().append(e));e.each(function(a){this.id=w+a});f.addClass(g+" "+d);l&&l.maxwidth&&f.css("max-width",u);e.hide().css(y).eq(0).addClass(j).css(x).show();F&&e.show().css({"-webkit-transition":"opacity "+h+"ms ease-in-out","-moz-transition":"opacity "+
h+"ms ease-in-out","-o-transition":"opacity "+h+"ms ease-in-out",transition:"opacity "+h+"ms ease-in-out"});if(1<e.size()){if(D<h+100)return;if(a.pager&&!a.manualControls){var A=[];e.each(function(a){a+=1;A+="<li><a href='#' class='"+w+a+"'>"+a+"</a></li>"});k.append(A);l.navContainer?c(a.navContainer).append(k):f.after(k)}a.manualControls&&(k=c(a.manualControls),k.addClass(g+"_tabs "+d+"_tabs"));(a.pager||a.manualControls)&&k.find("li").each(function(a){c(this).addClass(w+(a+1))});if(a.pager||a.manualControls)q=
k.find("a"),r=function(a){q.closest("li").removeClass(v).eq(a).addClass(v)};a.auto&&(t=function(){p=setInterval(function(){e.stop(!0,!0);var b=n+1<C?n+1:0;(a.pager||a.manualControls)&&r(b);z(b)},D)},t());m=function(){a.auto&&(clearInterval(p),t())};a.pause&&f.hover(function(){clearInterval(p)},function(){m()});if(a.pager||a.manualControls)q.bind("click",function(b){b.preventDefault();a.pauseControls||m();b=q.index(this);n===b||c("."+j).queue("fx").length||(r(b),z(b))}).eq(0).closest("li").addClass(v),
a.pauseControls&&q.hover(function(){clearInterval(p)},function(){m()});if(a.nav){g="<a href='#' class='"+E+" prev'>"+a.prevText+"</a><a href='#' class='"+E+" next'>"+a.nextText+"</a>";l.navContainer?c(a.navContainer).append(g):f.after(g);var d=c("."+d+"_nav"),G=d.filter(".prev");d.bind("click",function(b){b.preventDefault();b=c("."+j);if(!b.queue("fx").length){var d=e.index(b);b=d-1;d=d+1<C?n+1:0;z(c(this)[0]===G[0]?b:d);if(a.pager||a.manualControls)r(c(this)[0]===G[0]?b:d);a.pauseControls||m()}});
a.pauseControls&&d.hover(function(){clearInterval(p)},function(){m()})}}if("undefined"===typeof document.body.style.maxWidth&&l.maxwidth){var H=function(){f.css("width","100%");f.width()>u&&f.css("width",u)};H();c(I).bind("resize",function(){H()})}})}})(jQuery,this,0);

VS Code顯示如下：

可以看到第2行和第5行顯示向下的箭頭，表明可以隱藏該代碼塊。這是隱藏后的截圖：

可以看到第8行的開頭為a.pauseControls&&d.hover而第7行被隱藏。但是利用VS Code的格式化功能可以發現代碼是這樣的(注意開頭a.pauseControls)：

可以看到正常情況下不可能存在一種隱藏方法使得第15行被隱藏而第17行不被隱藏，這說明之前的混亂代碼隱藏的塊並不正確。

如果采用上述代碼，Bug-1必定能夠復現。推斷原因是隱藏塊功能采用較為統一的方法來判斷正常情況下的隱藏范圍，但是代碼結構混亂時往往就會對其造成干擾，導致Bug-1的出現。

Bug-1基本上是無害的，一方面是因為一般來說不會有人寫出如此混亂的代碼，另一方面是因為如果真的寫出了如此混亂的代碼，基本上也不可能會用隱藏功能，而且用了也不會影響代碼正確性。

• Bug編號：Bug-2
• Bug等級：Euclid
• 測試環境：Windows 10操作系統，Visual Studio Code 1.54.3
• Bug描述：在使用了中文插件的情況下，界面仍然會毫無征兆地變為英文。一般來說在打開新的文件等或是重啟VS Code后就會恢復正常。
• 詳情：

Bug-2出現時VS Code的界面會變為英文(此時其界面與英文版的界面完全相同，因此不提供截圖)，但是查看語言設置會發現仍是中文。

Bug-2發生頻率不高。從我使用VS Code開始至今(包括又專門做的多次測試)，Bug-2只出現過兩次。一次是在我某天打開VS Code時發現界面突然變成了英文，但此前一直是中文。我以為是我的設置被復原了，於是准備再設置一下中文，但是當我再次設置時我發現設置並沒有發生變化。我試着重啟了一下VS Code，它又變回了中文。

另一次是在我某次寫完一段C#代碼並准備切換工作區的時候，我關閉了所有的工作區、文件和文件夾，但是當我關閉以后，界面突然變成了英文。這次我並沒有理會，而是以英文的狀態下打開了另外一個已有的工作區，打開完成以后它又變回了中文。

——偶然遭遇過兩次Bug-2的筆者

由於Bug-2發生在啟動時或是切換工作前，推測是由於某些原因使得VS Code錯誤地加載了原始的配置，使得界面為英文。人工復現Bug-2的30次嘗試都失敗了。

對於不習慣英文的人來說，Bug-2會使使用者陷入短暫的“恐慌”狀態，使其用戶體驗下降，但是對使用VS Code本身沒有任何影響。

4.總評

總的來說，VS Code是一個較為輕量的代碼編輯軟件。“麻雀雖小，五臟俱全”，其本身體積小，但依靠其基本功能和眾多的插件可以實現許多復雜的功能。同時其界面簡約舒適，而且其幾乎沒有什么影響使用的Bug，因此還是非常推薦的。作為代碼編輯器來說，我對其並沒有什么改進意見。

定量化的評分如下：

	描述	評分（滿分 10 分, 良好 6 分, 及格 4 分，聊勝於無 1 分, 很差 -3 分）
核心功能	核心功能的設計和質量	10（可以勝任大多數的代碼編輯工作）
細節	細節的處理	9（有許多貼心的提示和方便的功能）
用戶體驗	不干擾用戶的使用	10（不會彈出任何干擾用戶的無關窗口）
輔助功能	輔助功能如皮膚	9（顏色主題等很強大）
差異化功能	獨特的功能	10（各種插件永遠滴神）
軟件的效能	占用內存、啟動速度等	8（體積小，速度塊）
軟件自適應性	聯網/斷網，不同屏幕，不同操作系統的使用	8（無較大差異，但斷網時不可安裝新插件）
成長性	記住用戶的選擇，適應用戶特點	10（用戶設置可以被記住）
用戶控制權	系統狀態有反饋，等待時間要合適。關鍵操作有確認提示，有明確的錯誤信息。	10（有錯誤信息，關鍵操作存在確認提示）
調試體驗	調試時能否給出較多的有用信息	7(可以完成基本的調試並顯示變量值)

Visual Studio部分

1.安裝

Visual Studio通過一個叫Visual Studio Installer的東西安裝。因為我已經安裝了Visual Studio，所以界面會有所不同。但大體來說還是一樣的。

可以看到其中的各種選項非常復雜，令人頭痛。一般來說需要根據自己的環境來選擇要安裝的組件。相比於VS Code，其安裝后的體積非常之大，安裝時間也非常長。但是選擇好相應的開發環境后，安裝完成即可直接使用，無需像VS Code一樣需要插件支持。

2.功能使用

相比於VS Code，Visual Studio的啟動慢上一些。啟動后可以選擇相應的項目以開始。這里我選擇一個已有的C++項目並打開：

可以看到其UI比VS Code復雜許多，其右側顯示了工程結構，下側則顯示了調試信息。

點擊上方的“本地Windows調試器”即可調試運行。下斷點並調試運行，界面如下：

可以看到下方顯示了追蹤信息，右側資源欄被隱藏，多出了一些用於調試的按鈕。這個設計還是比較人性化的。

選中調試——性能探查器進行性能分析，以CPU使用率為例，點擊開始。一會兒后其給出結果：

可以點擊相應的函數查看更具體的數據。

3.Bug發現

• Bug編號：Bug-3

• Bug等級：Keter

• 測試環境：Windows 10操作系統，Microsoft Visual Studio Community 2019(版本16.7.3)

• Bug描述：中文亂碼

• 詳情：

  如果采用普通的C++組件安裝，Bug-3幾乎必定會出現。此時頁面通常可以繼續輸入中文，但在其他地方會亂碼。嚴重時甚至會出現無法編譯的情況(此種情況一般是工程下的多個文件編碼不統一造成的)。下圖的C++項目即展示了這種亂碼的情況。

​ 無法編譯的情況並不常見。但只要是在cpp文件中使用中文，Bug-3必然能夠復現。此時如果運行，控制台輸出 的中文也是亂碼。下圖是這段代碼的輸出。

​ Bug-3很明顯是編碼問題。在非控制台中的Bug-3可以通過某個插件修復，但控制台中出現的Bug-3則需要通過 注冊表之類的方式修復。鑒於Bug-3非常影響用戶體驗，而在不使用插件的情況下無法修復Bug-3，且控制台中 修復Bug-3需要一定的技術水平，另外其嚴重時會造成無法編譯的情況，故將其分級為Keter。

• Bug編號：Bug-4

• Bug等級：Euclid

• 測試環境：Windows 10操作系統，Microsoft Visual Studio Community 2019(版本16.7.3)

• Bug描述：無法調試宏

• 詳情：

  在使用宏函數時，調試是無法進入宏函數的，無論是在宏函數里下斷點並單步進入還是在使用處下斷點(由於這是一個比較好理解的動態過程，此處無配圖)。推測由於宏是預處理的，預處理時並沒有將宏與其對應的展開聯系起來，因此完成編譯后調試時觸發了Bug-4。Bug-4對於習慣使用宏函數的人來說有較大影響，因為此種情況下很難確保宏函數的正確性。

• Bug編號：Bug-5

• Bug等級：Euclid

• 測試環境：Windows 10操作系統，Microsoft Visual Studio Community 2019(版本16.7.3)

• Bug描述：代碼色彩顯示混亂

• 詳情：

  Bug-5出現時，代碼中各個部分很可能不按原來的顏色顯示(例如基礎類型不再顯示為藍色)，很多時候甚至一個單詞(指變量名、函數名等)會有兩種顏色。目前觀測到的Bug-5可以通過重啟Visual Studio來消除。目前人工嘗試復現Bug-5的多次努力均告失敗。

  Bug-5應該算是極其罕見的Bug了。上編譯課期間我全程都在使用VS，但也只碰到過一次Bug-5。當時我在VS上寫了很久的代碼，在一次刪減的時候，我按了保存，隨后整個代碼顏色都混亂了。好多詞都是前 一半一種顏色，后一半另一種顏色。起初我還以為是我盯了太久的屏幕以至於眼花，后來發現並不是我的問題。我推測可能是因為我在刪減過程中使代碼變得不可編譯，但保存后VS照常執行了代碼高亮的操作，而由於本身代碼就是不能通過編譯的，可能導致VS在某些地方引起了誤判，從而導致了這樣的混亂。不過還好重啟以后就恢復了原樣。

  ——遭遇過一次 Bug-5的筆者

4.總評

Visual Studio是一個重量級的集成開發環境。相比於VS Code，其功能更多，也更適合開發。

但與VS Code不同，對於它我還是有很多建議的。事實上Visual Studio的報錯頻率極高，且一般都是普通開發者所不知道的一些奇奇怪怪的原因造成的。我個人使用的時候就碰到過許多令人匪夷所思的錯誤，而且這些錯誤大多都能在重啟VS后恢復。

總的來說，VS在提升用戶體驗上還需要努力。比如亂碼的問題，Visual Studio如果能自動把各個文件的編碼統一，用戶使用就會方便許多。另外可以把默認設置改為用戶較為習慣的設置。例如使用Visual Studio調試時偶爾會報“找不到文件”的錯誤，但事實上可以通過更改相關設置來排除此錯誤。

基於以上原因，我只能給出一般的評價。

定量化的評分如下：

	描述	評分（滿分 10 分, 良好 6 分, 及格 4 分，聊勝於無 1 分, 很差 -3 分）
核心功能	核心功能的設計和質量	10（集成開發環境不錯）
細節	細節的處理	4（很多地方根本不為用戶考慮）
用戶體驗	不干擾用戶的使用	-3（總會在一些奇奇怪怪的地方報錯，經常弄得用戶不知所措）
輔助功能	輔助功能如皮膚	9（顏色主題等很強大）
差異化功能	獨特的功能	9（集成開發環境種類多樣）
軟件的效能	占用內存、啟動速度等	6（內存占用大，啟動速度尚可）
軟件自適應性	聯網/斷網，不同屏幕，不同操作系統的使用	3（僅適用Windows和MacOS）
成長性	記住用戶的選擇，適應用戶特點	4（並不太長記性，難以給每個項目一個共同的基礎設置）
用戶控制權	系統狀態有反饋，等待時間要合適。關鍵操作有確認提示，有明確的錯誤信息。	10（有錯誤信息，關鍵操作存在確認提示）
調試體驗	調試時能否給出較多的有用信息	9(調用棧、變量值等都能較好地顯示)

二者對比

	VS Code	Visual Studio
核心功能定位	簡潔的代碼編輯器	完整的集成開發環境
目標用戶	任何人(因為可以把它當成一個純文本編輯器使用)，或者是實行輕度開發的用戶	重度開發人員，或是開發較為復雜應用程序的人員
適用需求	對代碼性能要求低、工程化方法低的場合	除包括前者外，還包括需要嚴謹分析代碼的各種度量指標、工程化方法高的場合
功能拓展	靠各種插件可以實現Visual Studio的基本功能	一般來說采用安裝時提供的各種組件即可
適應平台	全平台通用	僅限Windows和MacOS

通過以上的分析，二者的區別已經很明顯了。如果想以工程化的方法開發一套完整的軟件，Visual Studio無疑是最好的選擇，但如果只是想寫一小段程序，VS Code可能會更好，因為VS Code遠比Visual Studio輕量，使用起來更為快捷。

第二部分 分析

使用此服務的所有功能，估計這個軟件/網站/服務做到這個程度大約需要多少時間(團隊人數6人左右，計算機大學畢業生，並有專業UI支持)。

對於Visual Studio，我認為這是不可能的。它是一個集成開發的環境，想要開發這樣一款軟件，意味着需要很好地掌握包括但不限於編譯原理、數據庫原理、體系結構等方面的知識，而且幾乎每一個方面的開發任務都是異常繁重的，僅僅靠6人的計算機學院學生團隊，即使能開發出來，開發時間至少要以十年為單位計算。因此基本可以認為不可能。

對於VS Code，如果不考慮插件，我認為大概需要1-2年的時間。VS Code在不安裝任何插件的情況下，說到底只是一款代碼編輯器，並不負責代碼的執行。因此開發需要完成的任務只是實現這樣一款代碼編輯器，並為其增加插件功能。這對於6人的計算機學院團隊來說，雖然有些難，但還是可以實現的。只不過在VS提供的調試和代碼高亮功能等方面可能要多花點時間。

分析這個軟件目前的優劣(和類似軟件相比)，這個產品的質量在同類產品中估計名列第幾？

對於Visual Studio來說，其優勢是繼承了眾多開發環境，用起來比較方便；缺點就跟前面說的一樣，對其了解不深的開發者很可能會被一些奇怪的報錯弄得摸不着頭腦。我認為其質量在同類產品中可以排個第2或3位的樣子，畢竟感覺沒有Jetbrains的IDE好用。

對於VS Code來說，插件無疑是其最大的優勢。眾多的插件，使其能夠由一個普通的代碼編輯器成為一個輕度的集成開發環境。其作為代碼編輯器的缺點幾乎沒有，作為集成開發環境則比專業的集成開發環境弱了很多。但VS Code 定位是代碼編輯器，因此在我心中同類產品中VS Code排名第1。

從各方面的問題，推理出這個軟件團隊在軟件工程方面可以提高的一個重要方面(具體建議)。

這個前面也說過，Visual Studio應該更加注重着力於提升用戶體驗，如自動統一編碼、使用更人性化的默認設置等，不要讓用戶摸不着頭腦。

你在第一部分發現的bug，為何軟件團隊不能在發布前修復？他們是不知道，還是有意不修復？你覺得是什么原因？

首先，對於前文所述的Bug-1, Bug-2並沒有修復必要。而且Bug-2有可能是中文插件的Bug，並不是VS Code本身的Bug。

對於Bug-3，我認為是對用戶需求掌握不好。可能軟件團隊認為讓用戶自行決定文件編碼更好，但用戶一般情況下只希望方便快捷。

對於Bug-4我認為是團隊粗心大意和對用戶需求掌握不好兩種因素的共同影響。調試宏函數應該說是一個理所當然的需求，不應該被遺忘。

對於Bug-5我想是因為其發生頻率極低，因而被開發團隊忽視了(或者開發團隊沒碰到過此種情況)。

第三部分 建議和規划

市場概況

市場有多大？

據統計，全球的程序員至少有2億人，市場巨大。

直接的用戶有多少？潛在的用戶又有多少？

現有程序員中直接用戶占多，其余的均為潛在用戶。大學生等也是潛在用戶。

市場現狀

目前市場上有什么樣的產品了？

代碼編輯器有Notepad++, Vim等，IDE有Clion, Code Blocks等

上述產品的定位、優勢與劣勢在哪里？

上述提及的代碼編輯器定位就是代碼編輯器，它們的優勢是比VS Code更為輕便，而Vim的編輯功能比較強大。但VS Code與之不同的是其有眾多的插件可供使用，同時可以運行代碼。

和上述IDE比起來，VIsual Studio的優勢在於其集成了多種開發環境，但其他IDE基本只適用於某種特定的環境。但在專一方面的表現VS並不一定比它們好。例如C++方面的表現，Clion無論是自動補全還是調試功能，都要優於VS。

上述產品之間呈現什么樣的關系，哪些為競品關系？以及競爭中的各方態勢如何？

上述代碼編輯器(包括VS Code)都是開源的，因此不構成競爭關系。上述IDE中Clion與VS構成競爭關系，目前二者大概為分庭抗禮的狀態。

市場與產品生態

這個產品的核心用戶群是什么樣的人？典型用戶是什么樣的？學歷，年齡，專業，愛好，收入，表面需求，潛在需求都是什么？

考慮到大學生使用的一般為社區版，故核心用戶群應該為軟件開發工程師。學歷一般來說至少為大學以上學歷，年齡大概為22-50，專業應為軟件相關專業，愛好為編程，月收入5000-50w不等，表面需求為開發，潛在需求為高效地開發。

產品的用戶群體之間是否存在一定的關系？是否有利用其相互作用二次構成特定用戶生態的可能性？

使用社區版的大學生，在成為真正的開發人員后大概率會繼續使用專業版的VS。因此提供社區版以便使其從社區版向專業版進行過渡是一個很好的選擇。

產品的子產品，以及其他相關產品之間是否存在一定的關系？是否有利用各個產品特性之間的相互關系二次構成產品生態的可能性？

目前來說，VS本身沒有什么子產品，但可能會因為VS Code的影響而增加更多的用戶。

產品規划

你要在當前軟件的基礎上設計什么樣的新功能？為何要做這個功能，而不是其他功能？為什么用戶會用你的產品/功能？你的創新在哪里？可以用NABCD分析。

我會增加一個項目設置共享的功能，具體來說，是可以將自己的項目設置分享至網絡，同時他人可以直接一鍵采用該設置。

• Need：VS的設置極為復雜，如前面所說，其默認設置存在很多問題，設置不好就會遭遇很多奇怪的報錯，許多新人因此被勸退。如果能共享設置，則可以省去這樣的麻煩。
• Approach：使用戶能夠上傳對於某一項目的設置模板(例如針對C++的某個版本的Clang設置)，同時其他用戶能夠根據自己的項目特點一鍵使用他人設置好的模板。
• Benefit：免去設置不當造成的各種報錯苦惱。
• Competitor：如前面所說，用戶體驗是目前VS的短板，而此功能可以很大程度上改善用戶體驗，提高自己的競爭力。
• Delivery：增加用戶體驗后顯然會得到用戶的推廣。

如果你是項目經理，可以招聘6個人，並且有4個月的時間，你認為應該如何配置角色(開發，測試，美工等等) 才能在第16周如期發布軟件的改進版本，並取得預想中的成績。

1人美工，3人測試，2人開發。在依托現有VS的情況下，此功能應該並不復雜。相比於功能本身，考慮更多的應該是安全性，因此必須進行充分的測試。

請為你的團隊設計16個周期每周的詳細規划。

周次	任務
1-3	評估此舉的安全性問題，團隊達成共識並明確分工、制定規范
4-6	美工人員和開發人員需要共同完成Alpha版，測試人員需要完成基礎的測試庫
7	對Alpha版進行測試與評估，商討改進計划
8-10	針對改進計划進行進一步的開發，測試人員需要完成對安全性的專項測試
11-12	所有人員對其進行充分的測試，尤其是安全性方面的測試
13-15	發布產品的測試版並收集用戶意見，進行進一步的修改、迭代
16	發布正式、穩定版的產品