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的运行速度。一般来说,Microsoft自家的官方插件可以解决很多问题也不会有bug,不过有些支持(如Latex等)还是需要使用第三方插件来进行。

    • 优点:轻量,简便,上手难度低,可扩展和自定义能力极强。
    • 缺点:插件质量参差不齐,可能会有冲突和错误,插件过多会影响运行速度。
    • 改进意见:希望官方能够开发更多的插件,对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。

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

猜你喜欢

转载自www.cnblogs.com/sharinka0715/p/12501520.html