从Visual Studio 2017谈起，解析微软技术生态进化之道

   <p style="text-align:center"><img alt="从Visual Studio 2017谈起，解析微软技术生态进化之道" src="https://simg.open-open.com/show/7cfa34b27a0adc0bcc015c49aa347787.jpg" /></p>    <p style="text-align:left">作者｜何恺铎</p>    <p style="text-align:left">编辑｜尾尾</p>    <p style="text-align:left">曾经被业界取笑「闭关锁国」的微软如今也走向了「改革开放」的道路，Visual Studio 2017 的发布，不仅是 VS 二十周年的大事件，更是微软技术生态焕然一新的直观体验。以前只支持 Windows 及自家产品的微软，现在 iOS、Android、Mac 都支持了。</p>    <p style="text-align:left"><strong>写在前面</strong></p>    <p>北京时间 2017 年 3 月 8 日凌晨，Visual Studio 2017 如期发布。今年恰逢 Visual Studio 二十周年，Visual Studio 团队可谓诚意满满、不负众望——VS2017 不仅拥有全新的模块化设计和更强的性能，功能上也是具有颇多看点和干货，绝非不痛不痒的“年货式”更新。更重要的意义在于，它折射出了微软对于业界技术趋势的最新思考，也展现出了微软拥抱开发者社区的全新姿态。</p>    <p>大家可能还记得鲍尔默在众人前高喊"Developers, developers, developers!"的场景，这说明微软本有着非常重视开发者社区和开发者体验的传统。然而前些年，也许是失之于封闭和捆绑，微软在开发者群体中的影响力走势低迷。将各技术产品线进行排他性整合的思维最终被证明是不受欢迎的——在这个崇尚开源的互联网时代，它反而削弱了微软各大技术平台的竞争力。</p>    <p>好在新任 CEO 纳德拉执掌公司以来，给微软带来了巨大的思维方式的转变，开放与协作迅速成为了主旋律。 崭新的公司文化帮助微软的技术生态跳出了过去的窠臼和局限，并逐渐进入了一种生机盎然的绝佳状态。本文试图通过梳理 VS 2017 的诸多特性，从编程语言及其工具体系、移动和云、容器化和 DevOps 等不同视角来探讨 Visual Studio 乃至整个微软技术栈的基因变化，解析其进化之道。</p>    <p><strong>编程语言及其工具体系</strong></p>    <p>Visual Studio 2017 一如既往地为多种编程语言提供了原生支持，如C#、TypeScript/JavaScript、C++、F#、Visual Basic 等，也集成了这些语言的最新版本。</p>    <p><strong>C#语言稳步发展，开始支持模式匹配</strong></p>    <p>众所周知，VS 的当家语言是C#。C#现已是一门多范式的主流编程语言，历久弥新，LINQ、dynamic、async/await 等标志性特性使其在世界范围内拥有众多拥趸。新版 Visual Studio 按照惯例带来了全新的 C# 语言版本C#7，新增了 Out 变量（Out variables）、元组值类型(Tuples)、引用返回(Ref locals and returns)、本地函数(local functions)等特性。C#7 的演化思路很清晰，是在C#6 的基础上带来稳健的增量更新，使代码更为简练，可读性和可维护性更强，进一步巩固 C# 主流编程语言的地位。</p>    <p>最值得一提的新特性，恐怕要数<strong>模式匹配</strong>（pattern matching）了。这一标志性的函数式编程范式引入 C# 后，巧妙地融入了原有的 is 关键词和 switch 语句，可在诸多场合大幅简化繁琐的变量声明、if 语句和类型转换，凸显业务逻辑本身。</p>    <p>与此同时，我们还能够看到 C# 语言团队的谨慎和克制——因为模式匹配原本计划做得更加深入，如加入 match 关键词和类型分解（destructuring）等高级特性，但 C# 团队最终选择了暂时避免激进变化，采用了更温和更稳健的策略。这样的一种克制，对于 C# 这样具有较重历史负担和大量遗留代码的语言来说，是一种对庞大的用户群体负责任的态度，也降低了众多 C# 开发者学习和升级的门槛。</p>    <p><strong>Roslyn 编译器为 C# 发展推波助澜</strong></p>    <p>C#众多新特性的背后，离不开 Roslyn 编译平台的坚定支撑。历经数年孵化的 Roslyn 使用 C# 实现了一个现代的 C# 编译器，现已能完全替代原有的 C++ 实现，真正走向了成熟。任何语言的生命力源于一个开放的、架构良好的、可维护的编译器 code base，开源的 Roslyn 做到了这一点。像前面提到的模式匹配的类型分解，其实在 Roslyn 平台上实现并不困难，甚至已经有了初步的代码实现。因此，全新出发的 Roslyn 平台，是 C# 后续良好快速发展的保证，我们对 C# 的未来应当充满信心。</p>    <p>Roslyn 带来的另一个好处是强大的编译器 API 和元数据暴露能力，也在 VS2017 中得以体现，提高了生产效率。在使用 VS2017 时不难发现，最常用的查找所有引用（“Find All References”）的结果得到了良好的格式化和语法高亮，还支持更多的展现选项；“Ctrl + .” 的智能提示组合键也变得更加强大，覆盖了更多场景，还能帮助开发者迁移代码到C#7——这些都离不开 Roslyn 的加持。之前类似的功能可能需要通过第三方商业扩展（如 JetBrains 的 Resharper）才能拥有，而现在相当部分已经在 Visual Studio 中直接内置了。</p>    <p><strong>颇受好评的 TypeScript 持续快速迭代，同时支撑了新版 Visual Studio 中的 JavaScript 工具体系</strong></p>    <p>TypeScript 是微软近年来的另一个重大投入，由 C# 之父 Anders Hejlsberg 亲自掌舵，可以理解为 JavaScript 语言的一个超集。TypeScript 设计和发展的思路紧紧围绕两点：一是引入可选的强类型机制，以提供强大的编译期检查和智能提示；二是全面拥抱乃至提前实现 ECMAScript 标准，使得众多开发者可以第一时间尝鲜，不必等待浏览器的内置支持，而对标准的遵循也使得开发者的学习成本得以摊薄。</p>    <p>这两个正确的设计决定让 TypeScript 具备了鲜明的强类型生产力特征，同时又能与 JavaScript 和 Node.js 的已有社区成果深度兼容。因此，TypeScript 一经推出就广受欢迎，在近年不断获得关注和采用。如 Angular 框架团队于 2015 年宣布 Angular2 放弃自有的 AtScript 转而使用 TypeScript，堪称微软与谷歌开源技术合作的破冰之举。</p>    <p>毫无疑问，VS2017 自然内置了最新的 TypeScript 2.2 版本。除去在 Visual Studio 中开发和编辑 TypeScript 代码的丰富体验外，基于 TypeScript 的核心能力和强类型生态，Visual Studio 2017 还全新打造了 JavaScript Language Service（原开发代号"Salsa"）来支撑在新版 VS 中的 JavaScript tooling 体系。</p>    <p>换句话说，微软基于 TypeScript 的能力打造了为 JavaScript 开发服务的语言基础设施，类似 Roslyn 对于 C# 的基石作用，使得 VS 中 JavaScript 相关的智能提示、代码导航、代码重构等体验取得了大幅改进。之所以相关能力可以跃升，基于 TypeScript 的静态代码分析引擎功不可没，它替换了老旧的主要依赖动态执行获取信息的 Intellisense 引擎 。另外，JavaScript 编辑时上下文中的静态类型信息既可以来自 TypeScript 生态的大量强类型定义（主要由 DefinitelyTyped 项目提供），也支持解析社区常见的 JSDoc，这是又一个亮点。</p>    <p>TypeScript 近期版本还不断地加强了对 JSX 语法的原生语言级别支持（JSX 自 TypeScript 1.6 版本开始引入）。从面向 React.js 进行 JSX 特性的设计，一直到最近为 React Native 进行适配和优化——倾听社区声音的 TypeScript 非常接地气 ，体现了对流行框架的支持和融合。</p>    <p>微软技术栈中的其他语言，也在 Visual Studio 2017 中得到了更新，如C++、F#和 Visual Basic。其中，C++进一步实现了C++14 和C++17 标准中的特性，并开始支持跨平台开发；F#发布 4.1 版本，提出要成为具备最佳效率工具支持的现代函数式编程语言；而 Visual Basic 则将一定程度停止对 C# 的简单克隆，着重发展自己的特色。因篇幅所限，此处就不再展开。</p>    <p><strong>以 Visual Studio 2017 领军的 VS 家族已经完成布局，形成了一个开发生态的矩阵</strong></p>    <p>伴随着新生的 Visual Studio 2017 一起陆续走到前台的同门兄弟，还包括开源、跨平台、多语言支持的轻量级开发环境 Visual Studio Code 以及由 Xamarin Studio 发展而来的 Visual Studio for Mac（仍处 Preview 状态），它们都已是 Visual Studio 大家庭里的重要成员。</p>    <p>前面文中提到的C#、TypeScript 等语言的新版本和新特性，得益于相应语言基础设施的开放性和模块化，也都可以在 VSCode 和 VS for Mac 中找到并使用。例如 Visual Studio Code 中完善的 C# 支持，是通过一个巧妙的被称为 Omnisharp Server 的后台 Http 服务进程实现了对代码结构的实时解析和智能提示，而在 Omnisharp 背后进行支撑的正是 Roslyn。</p>    <p><strong>移动和云</strong></p>    <p>“移动为先，云为先”是微软的全新战略，因此 Visual Studio 2017 对这两方向的开发支持都进行了巨大的投入，达到了新的高度。</p>    <p><strong>移动开发方面微软采用了迂回策略，通过C#/Xamarin 和 JavaScript/Cordova 吸引两大阵营开发者，进军 Android/iOS 应用开发</strong></p>    <p>移动方面，去年微软成功地完成了对 Xamarin 的收购，终于将 Xamarin 赖以成名的利用 C# 编写 Android、iOS、Mac 等平台原生应用的能力收入囊中，并与微软产品线进行整合——此举受到了 .Net 社区的广泛欢迎。今天我们看到的 Visual Studio 2017 已经体现了整合的成果：用户们不必再额外付费购买昂贵的 Xamarin 商业套件，新版 Visual Studio 中已经直接纳入了使用 C# 语言和类库生态编写 Android/iOS 应用的能力，大幅降低了使用 Xamarin 技术的门槛。</p>    <p>并入微软官方体系之后，Xamarin 的生态也许将逐渐迎来真正意义上的繁荣时期。不过对于中国的广大开发者来说，国内目前 Xamarin 的声量还比较小，对国内移动互联网生态（如认证、分享、支付等）尚无太多的官方支持和兼容考虑，这可能会成为国内公司使用 Xamarin 进行移动开发的主要障碍。如果微软和社区在这方面进行积极的合作和推动，解决这样的“水土不服”问题，相信国内的 Xamarin 成功案例也将开始涌现。</p>    <p>除 Xamarin 外，微软在移动开发还有另一套基于 Apache Cordova 的解决方案，以吸引 JavaScript 和 Web 技术背景的移动开发者。Visual Studio 团队其实多年前就开始构建 Visual Studio Tools for Apache Cordova（简称 TACO），试图为开发者提供一站式的 Cordova 开发体验，帮助解决繁杂的安装、依赖梳理、环境配置、调试支持等工具链问题——这正是 Visual Studio 所擅长的。Visual Studio 2017 带来了新版的 TACO，在相关体验上再次上了一个新的台阶，还支持最新版本的 Ionic2 框架，有兴趣的朋友不妨一试。</p>    <p><strong>跨平台 .Net Core 走向成熟，成为适合云端的应用构建选择</strong></p>    <p>云计算方面，日前微软 Azure 在公有云领域稳居世界第二，且势头不断攀升，已是微软整体业绩的重要增长引擎。毫无疑问，Visual Studio 2017 不遗余力地为开发云端应用程序准备了最新最强的支持。</p>    <p>为云助力的第一要务，是帮助开发者构建适应在云端环境运行的应用程序。.Net Core 和 Asp.Net Core 在此处扮演了重要角色，因为它们具有良好的跨平台支持，并且能够比较轻量地连同整个 runtime 一起打包进行自包含部署（Self-Contained Deployment）。之前 .Net Core/Asp.Net Core 曾在 Visual Studio 2015 中试水，并随着技术思路的调整在 VS2015 的多次更新中不断变化。终于，Visual Studio 2017 正式将蜕变完全的 .Net Core 和 Asp.Net Core 项目作为一等公民。之前因为 .Net Core 生态处于预览状态而担心稳定性和 breaking change 的朋友们，现在则可以放心大胆地使用了。</p>    <p>.Net Core 和 Asp.Net Core 的历史和关系说起来颇为有趣：多年前 Asp.Net 团队在微软内部就以开放和进取著称，他们在设计下一代的时称 Asp.Net 5 的框架时（早期代号为 Project K ），雄心勃勃地希望加入自包含部署、即时编译、跨平台运行等特性，并在当时 .Net 的工具链和运行时尚不能支持相关需求的情况下，竟自底向上地开发出了一套相对独立的生态和工具链（DNX），事实上领先于 .Net Core 的孵化。Asp.Net 5 的预览版发布后，在设计和性能上都取得了相当好的反响，声势上反倒盖过了标准 .Net Core Tooling，一度造成了略显尴尬、令人费解的局面。</p>    <p>令人高兴的是，经过了一段相当长的过渡时期后，两个团队逐渐走向了协调和融合，期间 Asp.Net 5 重命名为了 Asp.Net Core，并最终完全基于 .Net Core 的 CLI 进行管理和运行。直到最近 Visual Studio 2017 发布时，DNX 工具链的最后标志 project.json 描述文件也随着 .Net Core Tools 1.0 的正式交付而退出历史舞台，进化后的 csproj/msbuild 体系则再次统一项目模型。这一段轶事其实也折射出了微软自我革新的历程，可谓好事多磨，终成善果。</p>    <p><strong>Azure 上的 PaaS 能力不断推陈出新，Visual Studio 帮助大幅降低使用门槛</strong></p>    <p>为云助力的另一角度，是需要为 Azure 上琳琅满目的 PaaS 特性提供支持和无缝集成，这部分一直由 Azure SDK 进行支撑。在 Visual Studio 2017 的 Azure 套件中，自然包含各种基于 PaaS 的云端项目模板，为用户采用 Azure 的特性提供了一站式解决方案，典型的如 WebJob 和 Service Fabric。而对于需要消费 PaaS 和各种标准 API 的应用程序，Visual Studio 的 Connected Service 也能够帮助开发者迅速地连接和配置这些平台或服务。此外，Azure SDK 所包含的 Azure 模拟器可以帮助开发者在本机虚拟云端环境，极大地方便了云端应用程序在本地的开发和调试。</p>    <p>针对大数据处理和计算的 PaaS 能力是当前公有云厂商争夺的重点。Azure 近来在此领域内动作频频，一方面不断深化与 HortonWorks 的合作，高频率地强化和更新 HDInsight（基于 HDP）；另一方面 PaaS 化程度更高的 Azure Data Lake 也已结束了预览进入 GA 状态。Azure Data Lake 上的数据分析颇具特色，可使用微软自研的U-SQL 语言结合 SQL 和 C# 的特点进行混合编程，给大规模数据处理和查询带来了让人耳目一新的方式，受到 .Net 生态开发者的欢迎。在 Visual Studio 2017 中，开发者可以很方便地连接和管理云端的大数据资产，并创建相应生态的应用程序，如U-SQL、Storm、Hive、Pig 等。</p>    <p>总结移动和云方面，微软可谓兼收并蓄，与时俱进。同时，通过充分利用 Visual Studio 这样的生产力工具，微软成功地对各种平台和不同层面运行环境下的开发单元进行了良好的抽象，给予了开发者多样化的选择。</p>    <p><strong>容器化和 DevOps</strong></p>    <p><strong>微软同 Docker 进行深度合作，融入容器生态圈</strong></p>    <p>容器化和 DevOps 已成行业热词，微软自然不会错过相关生态的布局，之前就成功而及时地与 Docker 达成了深度合作。在这个领域，微软做了三件看起来非常具有前瞻性的事情，一是与 Docker 合作催生 Windows 容器，包括 Windows Server Core 和 Windows Nano Server 两种形式，以方便传统 Windows 应用程序向 Docker 容器迁移；二是着力优化 Windows 作为 Docker 宿主的能力和体验，使得 Linux 容器能够通过 Docker for Windows 稳定轻快地运行于开发人员 Windows 上，Docker 的原生支持也添加进了 Windows Server 2016 中；三是不失时机地推出了 Azure 容器服务（Azure Container Service），使得基于容器的大规模应用程序能够顺利地在微软云中部署生根。</p>    <p>受益于上述策略的不断落地，在 Visual Studio 2017 中进行流畅的容器化应用开发可谓水到渠成。我们可以轻松地为相关 Project 添加 Dockerfile 打包应用进容器，并在 Solution 层面使用 Docker Compose 进行容器编排。笔者曾尝试在较短时间内建立起若干简单的 Asp.Net Core 微服务，并互相组合形成了基于微服务架构的应用程序，然后通过 Visual Studio 在本机的多个 Linux 容器上一键部署运行。更方便的是，Visual Studio 2017 还帮助生成了 .Net Core 调试相关的 Docker 配置，使得调试模式下运行在 Linux 容器内的代码轻松地命中了 VS 内的预设断点！这样的单机多容器“远程”调试确乎是一种奇妙的体验。</p>    <p><strong>Azure 容器服务是微软云的容器解决方案，支持多种编排引擎</strong></p>    <p>前面提到的 Azure 容器服务，值得再略着一些笔墨。有不少人认为，容器生态的不断发展对于传统 PaaS 形成了强而有力的挑战，因为细粒度的容器一定程度上可以替代 PaaS，同时提供更大的灵活度以及可移植性——很多情况下的确如此。在这一问题上，Azure 选择了两边下注，在继续不断发展 PaaS 的同时（比如积极投入 Azure Functions 这样的 Serverless 计算框架），也拥抱容器生态，推出并不断改进 Azure Container Service 。保留不同粒度的抽象，把选择权留给客户，的确是最佳方案。目前 Azure 容器服务已支持 Docker Swarm、Mesosphere DC/OS 和 Kubernetes 三大编排引擎，同时底层利用 Azure VM Scale Set 特性优美地实现了弹性扩容。</p>    <p><strong>VSTS/TFS 提供了现代的持续集成能力</strong></p>    <p>真正的 DevOps 离不开持续集成 pipeline 的搭建和管理。在大家的印象中，Visual Studio 一直有比较好的手动发布支持，可以方便地一键部署应用程序至本地或云端。Visual Studio 2017 已更进一步，通过与云端 Visual Studio Team Service (VSTS)或本地 Team Foundation Server (TFS)的深度配合，可彻底将 CI/CD 的流程串联并打通，实现自动编译、测试、发布和部署。</p>    <p>最新版本的 VSTS/TFS 不但让完整的 DevOps 流程开箱即用，并且从设计理念上充分考虑了开放性，可以在 CI/CD pipeline 的不同环节使用不同的技术：如使用 GitHub 的仓库进行源代码获取和编译触发，又如支持以 Docker 为构建和发布的基本单位，再如使用 Octopus Deploy 进行部署等。此间，Azure 也扮演重要角色，既可以提供动态伸缩的 Build Agent，又能够作为应用最终部署的目的地。</p>    <p>DevOps 流程中容易忽视的一个痛点在于关系型数据库 schema 的版本控制和升级，实践中往往需要依赖手动编写的迁移脚本进行人工操作——这与 DevOps 的精神是相违背的。为了尝试解决这一问题，微软与第三方工具提供商 Redgate 进行了合作，首次将价值不菲的 Redgate Data Tools 内置于 Visual Studio 2017 企业版中。Redgate 相关工具的妙处在于，不仅能够将数据库 schema 进行完善的源代码管理和编译检查，更能记录不同版本的演化细节，并在 VSTS 的配合下自动地增量更新到 CI pipeline 的各个数据库中，包括在审批后到达最终的生产环境。</p>    <p><strong>展望与期待</strong></p>    <p>不知不觉，Visual Studio 已经走过 20 个年头。 Visual Studio 2017 是一个重要的里程碑，同时也是一个新的开始。<strong>我们有理由相信 VS2017 还将不断升级，把握新的机遇</strong>。事实上，微软已经开始为 VS2017 准备后续的更新，并紧锣密鼓地发布了 Visual Studio Preview，使得开发者们能够在正式的 Update 发布之前就可以率先尝试即将到来的新特性。</p>    <p>通过 Visual Studio Preview 我们可以知道，在未来的 VS2017 Update1 中，全新的 Python 开发环境将粉墨登场，还会带来支撑 Windows 10 Creator Update 新特性的 UWP 套件更新。之后，还会有针对数据科学和分析类应用程序（Data science and analytical applications）开发的专属支持。相信这些将来的更新都会广受欢迎。</p>    <p><strong>针对中国的开发者群体和市场环境，Visual Studio 团队想必也会越来越重视</strong>。近期微软与华为的合作就是一个很棒的成功案例：华为通过使用 VS2017 进行面向 Linux 的 C++ 开发，大幅提升了生产效率。 在此，我们也期待 Visual Studio 未来能够做得更多更好。其实除了解决部分组件水土不服的问题外，Visual Studio 还大可以尝试与国内的公司、平台和生态进行更深入的合作。让我们大胆试想，如果 VS 能够支持微信小程序的开发，或是在 VS 中能够方便地对接使用阿里云的基础设施，是不是听上去就更有诱惑力了呢？</p>    <p><strong>写在最后</strong></p>    <p><strong>"Any Developer, Any App, Any Platform"</strong>，Visual Studio 2017 在这样的新口号下酝酿和诞生。<strong>开放而非封闭，合作而非拒绝，兼容而非分裂，这是属于微软的改变，这是属于微软的进化之道</strong>。众多微软技术生态爱好者们期待已久的春天，似乎真的要到来了。也许有一天，我们不再需要强调“微软技术栈”，因为它本就是开放技术世界的组成部分，互相融合，难分彼此。</p>    <p>注：本文仅代表作者个人观点。作者个人与文中所提及商业公司均无利益关系。</p>    <p><strong>作者介绍</strong></p>    <p>何恺铎，供职于国双科技(Nasdaq:GSUM)，现任高级技术总监，负责网站与流量分析产品线。曾参与架构和设计了国双多个面向数字营销和社交聆听的大数据解决方案。个人关注的技术领域包括 .Net 生态系统、云计算、大数据技术栈等。</p>    <p>来自: <a href="http://mp.weixin.qq.com/s?__biz=MjM5MDE0Mjc4MA==&mid=2650995704&idx=1&sn=092cba8bcfe5e9e2832e548fc7d89215" id="link_source2">mp.weixin.qq.com</a></p>