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分。

这里打分的标准，也只能从我的角度出发对其进行评价，不能够代表所有人的观点（例如吃内存这种问题在很多人眼里不是问题）。

指标	Visual Studio	Visual Studio Code
功能数量	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。

  想做这个功能的原因，一个是用户已经赞扬并且可能会更喜欢自定义，还有就是这将成为我们品牌的噱头和卖点，是推销的绝佳方向，有助于开拓市场。