BUAA 2020 軟體工程 軟體分析案例作業

Author: 17373051 郭駿

項目	内容
這個作業屬于哪個課程	2020春季計算機學院軟體工程(羅傑 任健)
這個作業的要求在哪裡	個人部落格作業-軟體分析案例
我在這個課程的目标是	學習軟體工程的開發知識，培養工程化開發能力
這個作業在哪個具體方面幫助我實作目标	分析成熟的軟體，加深對軟體工程的了解

前言

我選擇進行分析的産品為微軟公司的兩個代碼編輯器：Visual Studio（以下簡稱VS）和Visual Studio Code（以下簡稱Code）。這兩款軟體名字隻相差一個單詞，但功能上卻是天差地别。它們無論是目标使用者、主要功能還是設計思路，都不盡相同。

選擇這兩款軟體的原因，一是我對這兩款軟體比較熟悉、比較親切，也是我用的最多的兩款寫代碼時用到的軟體。二是這兩款軟體有很多相同和不同之處，拿來對比更能夠展現出兩者的長處和不足，也能使得這篇調研報告更加立體、全面。

第一部分 調研評測

軟體介紹

為了更好地了解這兩款軟體，我們先來看看官網上是怎麼介紹它們的。

• Visual Studio: 大型內建開發環境

  

  可以看到，Visual Studio的功能真的非常多、非常全面。開發、分析、調試、測試、協作、部署，使用VS這一個工具，就能夠完成一款軟體開發的全部流程，包含了軟體整個生命周期所需要的大部分工具。

  而且，VS所支援的開發類型非常廣泛。從最簡單的控制台程式，到.NET桌面開發、Unity遊戲開發、移動開發、Linux開發、Web開發、跨平台軟體開發、資料處理和分析、Office開發，甚至VS自己的擴充插件的開發……VS可以說是無所不及，幾乎沒有什麼開發不能用VS來進行。

  同時，VS還支援一些插件，幫助完善VS沒有或者不夠全面的功能，支援了定制，讓本就全能的VS更上一層樓。

• Visual Studio Code: 輕量化文本編輯器

  

  相比于VS，Code的功能顯然少了許多，但是體積也幾乎是VS的百分之一。在官網界面，Code主打的功能隻有四個：代碼智能提示、Debug工具、内置Git、擴充插件。但其實用過Code的人都知道，第四個功能擴充插件的威力，可以吊打所有與其對标的文本編輯器。其具有極高的定制化能力和可拓展性，甚至可以将Code配置到功能數量不輸VS。Code還支援Linux環境下使用，可以說是一款全平台的文本編輯器。

Visual Studio所對标的軟體：IDE，如JetBrains家的IntelliJ IDEA，PyCharm等，以及開源編輯器Eclipse，Apple公司的Xcode等。

Visual Studio Code所對标的軟體：文本編輯器，如Notepad++，Sublime Text，Atom等。

可以看到，這兩款軟體的競争對手不同，功能形态上也各異。是以微軟開發兩個編輯器和開發環境是有意義的。

軟體體驗

• Visual Studio

  

  上次的個人項目作業便是使用VS完成，是以我直接拿來作為示範項目。

  這個軟體的使用體驗非常良好，因為它什麼都不缺。

  想要寫好看的代碼？VS幫你排版、智能檢查錯誤。

  想要Debug進行調試？VS提供斷點調試，且程式異常結束時能追溯異常位置。

  想要進行單元測試？VS提供内置單元測試架構，幫你全面覆寫程式。

  想要進行性能測試？VS能繪制精美的性能分析圖，幫你優化程式。

  甚至還能夠通過VS直接部署到Azure或者Git上，完成所有的流程。

  這款軟體幾乎可以解決開發過程中所有的疑難雜症，能夠解決使用者的大部分問題。

  不過，既然這款軟體功能這麼多，顯示的資料如此繁雜，無疑會給使用者帶來上手門檻。如果是程式設計入門的初學者，使用VS作為他們的開發工具無疑是困難的。哪怕是有經驗的開發者，想要玩轉VS也是相對困難的。

  因為功能繁雜，是以引起錯誤的原因可能很多，許多報錯也較為抽象，常使人摸不着頭腦。微軟提供的官方文檔也不一定能夠解決問題，常需要借助搜尋引擎來解決。

  同時，VS的體積較大，安裝起來很耗時。雖然Visual Studio Installer支援子產品化安裝IDE功能，不需要的功能可以不安裝，但依然會占用硬碟幾個G的空間，幾乎大于市面上所有IDE。

  • 優點：功能全面，覆寫完善，資料詳實，一切開發過程在同一款軟體内完成。
  • 缺點：體積大，界面内容太多，上手難度高，幾乎沒有人能同時用到的所有功能。
  • 改進意見：希望能夠内置更多的功能說明，将功能更加細分子產品化，不需要的部分可以不用下載下傳，進而縮小最小軟體體積。
• Visual Studio Code

  

  相比起VS而言，Code的界面非常幹淨清爽。作為一款文本編輯器而言，其幾乎沒有上手門檻。而且，作為後起之秀，Code大方的接納那些用慣了其他編輯器（Emacs、Vim、Atom）等編輯器的使用者，可以通過插件配置友善的改變快捷鍵布局。

  使用過Code的人，想必一定會體會到，插件是Code的靈魂，Code的強大幾乎全部來源于插件。甚至是安裝後的本地語言支援，都需要通過插件商店來進行下載下傳。對于程式設計語言的支援，各種擴充配置的支援，也都來源于插件。你想讓Code做什麼，就去插件商店裡找就好了。甚至Code還支援網易雲音樂插件，可以說是什麼都會。

  

  但同時，過于依賴插件也算是Code本身的一個缺陷。首先，沒有插件的Code文本編輯功能就是個套了層皮的記事本，除了能自動把Tab轉換為4個空格以外，編輯上和記事本也沒什麼差距。對于Debug功能，也需要使用者自己去編寫

  launch.json

  檔案來進行調試，各種編譯器參數都需要使用者自己設定，不能像VS一樣一鍵完成。

  雖然我們說插件很強大，但是插件依然沒能做到将Code變成VS。例如Code的C++ Extension，并不支援像VS一樣，以工程的形式去編譯運作C++程式。我們需要自己設定，對于開發者來說也算是額外的學習成本。插件無法幫助Code追平與專業級軟體的差距。

  在插件商店中，插件品質同時也參差不齊，也有一些功能重複或者沖突的插件。如果插件裝得太多，可能會拖慢Code的運作速度。一般來說，Microsoft自家的官方插件可以解決很多問題也不會有bug，不過有些支援（如Latex等）還是需要使用第三方插件來進行。

  • 優點：輕量，簡便，上手難度低，可擴充和自定義能力極強。
  • 缺點：插件過多會影響運作速度，且插件無法幫助Code追平與專業級軟體的差距。
  • 改進意見：希望官方能夠開發更多的插件，對C++等語言提供更智能或圖形化的編譯運作流程，貫徹易用這一标準。

分析完之後，我進行了進一步的思考。我在上面所提到的有些“缺點”未必是缺點，反倒可能是這款軟體的核心閱聽人所追求的形式。

在我眼中，VS的臃腫和備援，在大型程式開發者眼中可能意味着全面和智能。

在我眼中，Code的插件依賴，可能恰好是自定義愛好者眼中的财富。

就像是大部分普通家庭熱愛Windows，而開發運維人員鐘情Linux一樣，這兩款軟體的關系更是如此。它們不是優秀和劣質的差別，而更像是斧子和榔頭的關系，各有所長，能夠在各自的閱聽人群體中發光發熱。指望他們做到十全十美，“老少通吃”，更是不可能的。就像多、快、省隻能做到三者其二，這兩款軟體更不可能做到讓所有人都無法挑剔。

因為我隻是一名大三的學生，雖然同時使用這兩款軟體，但又不是這兩款軟體真正的核心閱聽人。我隻是在利用他們學習開發能力，是以軟體的很多特色在我眼中成為了缺點。這是是我作為一個個體，對一款閱聽人廣泛的軟體提出評價的局限性。

是以，雖然我對這兩款軟體進行了評價，但絕不代表這兩款軟體就應該向我“指點”的方向去開發改進。他們的差異化和顯著的特色，反倒是這兩款軟體立足的根本。

定量評價

這裡對兩款軟體進行打分，每一項滿分為5分，最低分為1分。

這裡打分的标準，也隻能從我的角度出發對其進行評價，不能夠代表所有人的觀點（例如吃記憶體這種問題在很多人眼裡不是問題）。

名額
功能數量	5（本就全面，還有插件）	4（大多依賴插件，且插件功能達不到專業軟體的水準）
定制能力	3（插件商店規模不大）	5（是真的什麼都能幹）
軟體适應性	3（沒有Linux端，對電腦組態有要求）	5（PC全平台，甚至有網頁端，輕巧不吃配置）
軟體效能	4（吃記憶體）	4（插件多了就會有加載延遲）
界面友好度	3（功能太多，眼花缭亂）	4（大多都好用，但很多插件沒有合适的界面，需要編輯json）
平均分	3.6	4.4

我個人還是更偏好Visual Studio Code，因為他還加入了對遠端開發、Docker、Jupyter Notebook等的支援，我也沒有很大型的工程項目需要IDE替我管理，是以VS略顯備援。不過，相信也有不少的人會更喜歡Visual Studio，因使用環境而異。

對于VS的評價：好，不錯

對于Code的評價：非常推薦

Bug尋找

說實話，對于Microsoft家招牌級的兩款産品，想要尋找到作業要求所說的“功能性的比較嚴重的Bug”十分困難。不過，老師告訴我們找到的隻要是Bug就行，我也就在下面提出了幾個一般性的、界面或者便利性上的Bug。

• Visual Studio的Bug

  1.Enterprise版本對單元測試代碼覆寫率的支援出現錯誤。在本地環境下，按照微軟官方提供的教程，使用正常的流程進行單元測試後，點選“代碼覆寫率結果”按鈕時，出現以下錯誤。搜尋後發現，這是一個在VS2015年代就有的問題，到現在依然會觸發。

  

  2.使用VS進行C#的.NET窗體開發時，若電腦縮放比例不為100%，則會不斷提醒你“以100%比例打開VS”，而當你以100%比例打開後，又會不斷提示你“以自适應分辨率打開Visual Studio”，反複提醒。

• Visual Studio Code的Bug

  1.Python Extension中，對Anaconda的支援出現錯誤。Anaconda原生支援cmd，本身不支援在Powershell中激活虛拟環境，需要經過特殊的設定。而Code本身預設的Terminal就是Powershell，但Python Extension沒有對其進行設定，導緻無法在Code中激活conda虛拟環境。

  2.在檔案中的文本資訊過長時，Code插件中距離較遠的括号比對、引号比對功能均會失效，導緻某些文法高亮功能失效。常見于對長json檔案的支援中。

第二部分 分析

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

  如果是6人團隊的大學生，無論是想要實作VS還是Code，即便有專業UI的支援，即便預設我們已經學會所有相關的技術，所剩的隻是設計和寫代碼，所消耗的時間也會在五年以上。如果還要我們去學習相關的技術，那所消耗的時間在七年以上都毫不誇張。因為這兩款軟體實在太強大，功能太多。

  如果隻是實作Code本體而不實作官方提供的所有插件，可能難度低一些，大約兩年以上，但設計插件接口标準也不是簡單的事情。

  實作VS本體更不用談，功能實在太多太複雜，很多已經完全超出了我的了解範疇，我現在能做出的所有估計都是抽象而不切實際的，很有可能會比這個時間更長。實作VS所有功能，工期在五年以上毫不誇張。

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

  優勢：功能全面，超過同類幾乎所有的競品，同類産品中排第一不過分。

  VS所提供的支援廣泛性遠超過其他單品IDE，例如JetBrains家的所有IDE可能要加起來才能和VS相比。VS雖然不支援Java，但是對Microsoft自家的.NET Framework支援無人能出其右。

  Code的插件清單更是超越同等級的文本編輯器，哪怕是Microsoft官方開發的插件就足夠匹敵許多編輯器，再加上第三方插件，功能應該是最全面的。

  

  這張圖是2020年3月，全球IDE搜尋下載下傳量的排行榜。VS占有率24.08%遙遙領先，其競品Eclipse，Android Studio屈居二三位。Code占有率第四，作為一款文本編輯器，已然超越很多功能齊全的IDE，與Code對标的Sublime Text，Atom隻排在第9、第10的位置，且占有率在下降，而Code的占有率猛漲。或許因為Code是後起之秀，是以占有率還在上升期間，但也已經打敗了所有的對标産品。

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

  Microsoft的軟體給我一直以來的印象就是，有時會在意想不到的地方出錯，且報錯資訊十分迷幻，參考價值較低。XP時代，我們見到最多的報錯就是記憶體0xblabla出錯，該記憶體不能為"read"/"written"，且下面的“确定”和“取消”按鈕作用幾乎相同。

  

  如今Win10時代，這種錯誤幾乎已經見不到，微軟的報錯風格開始轉變為有關此問題的詳細資訊，請通路http://microsoft.com/blabla。這樣的報錯無論是在Windows藍屏時，還是在上面VS出錯時，都很常見。但其實我通路了這個頁面也并沒有得到合适的解答。

  或許我不該苛求Microsoft團隊做出多麼大的改變，因為畢竟無論是Windows系統還是VS，都是長期以來靠積累形成的龐大工程，要改變其中任何一個子產品都是困難的。但我依然還是建議，希望團隊能夠将報錯資訊更加詳細化、通俗化，起碼能夠讓軟體的閱聽人能夠較好的了解發生了什麼樣的錯誤。對于通路這樣一個網址還沒有給超連結點選的行為，十分迷惑。

• 你在第一部分發現的bug，為何軟體團隊不能在釋出前修複？他們是不知道，還是有意不修複？你覺得是什麼原因？

  • Enterprise版本對單元測試代碼覆寫率的支援出現錯誤

    這個錯誤出現并不廣泛，但也不罕見，之前據說在VS2017中修複過一次，但被我在2019中又碰上了。原因可能是測試人員并沒有在特殊的配置環境下測試，進而導緻出現這種錯誤。

  • 縮放比例反複提問

    這個bug屬于便利性bug，原因可能是沒有掌握清楚使用者需求，才導緻這樣的循環提示。其實這種提示未必會給我帶來多大的困擾，但會讓我重新開機一次到兩次VS，沒有把握清楚我的需求。

  • Anaconda和Powershell的支援

    這個鍋Anaconda和Microsoft開發人員鍋各占一半。對于微軟的開發人員而言，顯然是測試人員并沒有測試出Conda和Powershell的不相容，或者是知道這個bug但是懶得修複。私以為後者的可能性更大，因為這還算是一個比較嚴重和廣泛的問題。

  • 長檔案中字元比對失效

    這個不應該責怪Code的開發人員，因為過長的檔案無論是使用正則比對，還是抽象文法樹進行建構，開銷都是極大的。Code犧牲了一定的插件性能，換來了檔案打開速度的提升。相比起金山WPS，打開一個大檔案不會犧牲比對功能，但需要幾分鐘，這是設計思路的不同，或許是feature，但Code也可以根據使用者配置的不同做到更好。

第三部分 建議和規劃

這個軟體/網站/服務有很多可以提高的部分，如果你是新上任的項目經理，如何提高進而在競争中勝出？

• 首先，市場有多大？潛在的使用者有多少？

  市場幾乎是面向所有的程式員，還存在一些學生和技術愛好者等潛在使用者。

• 目前市場上有什麼樣的産品了，它們的優勢劣勢在哪裡?和它直接競争的産品在那裡？

  市場上存在許多IDE和文本編輯器，他們的通病有：

  1.所支援的程式設計語言或者功能不夠全面，市面上的IDE是特化的工具，做不到全能

  2.可擴充性不足，插件商店要麼沒有，要麼不夠熱鬧，大部分人囿于原本功能

  3.售後保障不足/生态鍊不夠完善/社群不夠熱鬧

  與VS和Code競争的核心産品有JetBrains IntelliJ IDEA，Eclipse，Apple Xcode，Github Atom，Sublime Text等。

• 你要設計什麼樣的功能？為何要做這個功能，而不是其他功能？為什麼使用者會用你的産品/功能？你的創新在哪裡？

  我想設計的功能是進一步增加可定制化功能，讓定制變得更加簡單易用。對于插件開發者，我們想要提供更詳細的文檔或者可視化工具來協助開發；對于插件使用者，我們想建立更簡單的插件使用體系，一鍵安裝，一鍵使用。

  這個功能是Code的核心功能，也是Code一直以來的賣點。在VS上使用已有的成功經驗來擴充改進這個功能，将會成為我們産品最有利的核心競争力量。因為Code在此方面的進展已經初有成效，使用者十分喜歡高度定制化的Code，是以我們有理由相信使用者會更願意自定義他們的IDE。

  想做這個功能的原因，一個是使用者已經贊揚并且可能會更喜歡自定義，還有就是這将成為我們品牌的噱頭和賣點，是推銷的絕佳方向，有助于開拓市場。