.NET应用迁移到.NET Core（二）风险评估
2016年12月1日下午微软技术大会Microsoft Ignite China，有幸和大家分享一门课程，课程信息如下，欢迎大家到时来捧场。本文介绍下应用迁移的风险评估。
很多移植项目超出预算或未能按时完成，主要是因为没有很好地管理移植过程中可能遇到的风险。风险是在估计进度和资源时要考虑的一个重要因素。在应用程序移植项目中，这些风险来自与移植相关的不同方面，主要包括下面几种：
移植工程师的技能水平和移植经验。
使用的编译器。
使用的编程语言。
第三方软件和中间件的可用性。
编译环境和工具。
平台依赖的结构。
平台和硬件依赖的代码。
需要搭建的测试环境。
用户界面需求。
依赖于要移植的具体应用程序，以上各个方面的每一个都可能给移植项目带来不同的复杂度和风险。评估这些复杂度和风险的级别，可以帮助你确定它们是不是可管理的。
应用程序移植和软件开发最明显的区别就是编程人员所掌握的技能。虽然软件开发人员往往是某一领域内比较专业的人员，但是要做软件移植的开发人员却需要更宽广的知识和技能。一个应用程序开发人员可以是Windows开发环境上的.NET专家，或者是Windows操作系统上SQL Server的数据库专业开发人员；但是，从事代码移植工作的工程师却通常需要时两个或者更多操作系统、编程语言、编译器、调试器、数据库、中间件或最新的基于网页的技术方面的专家。他们还需要知道怎样安装和配置第三方数据库或中间件。
应用程序开发人员需要的往往是专才，而移植工程师则多是通才。应用程序开发人员可以为一个软件工作18个月，但是移植工程师在一个项目上往往只需要工作3~6个月，并且在上一个项目完成以后，即可投入下一个新的移植项目中。为一个移植项目找到完全适合的移植工程师有时候是很困难的，从老的技术移植到新的技术上时尤其如此。
在Windows平台上使用的编译器和编译器框架，与Linux平台上使用的有很大不同。如果在Windows平台和Linux平台上使用的是相同的编译器，移植工作将会变得容易一些，例如在两个平台上都是用的是GNU编译器，除了-g和-c标志外，不同的编译器使用的编译器标志可能大不相同，尤其是应用程序使用C++语言的时候。
另外一个需要考虑的事情是编译器的版本。要移植的代码可能是几年前使用老版本的编译器编译的，这些代码可能使用了与新的编译器不同的语法，这就使得在不同的编译器上移植程序比较困难，因为这些编译器可能支持也可能不支持老的标准，即使新的编译器支持老的标准，不同编译器对这些标准的支持方式也可能不太相同。
.NET Core项目的C# 编译器的实现非常完整，和.NET编译器实现遵循同样的ECMA标准的“Roslyn”新编译器，大大降低了移植.NET项目的难度。
当待移植的应用程序使用了第三方软件或中间件时，移植的复杂度会随之增加，尤其是在目标平台上没有这些第三方产品时，移植的难度会更大。可能会出现在Linux 平台上没有可用的第三方产品。在过去的几年中，一些中间件厂商，例如IBM，Oracle等都把他们的中间件产品移植到了Linux上。他们花了一些功夫，使那些已经使用或者准备使用Linux作为企业平台的公司在Linux上可以使用它们的中间件产品。这也是为什么越来越多的公司愿意把应用程序从Windows移植到Linux上的部分原因。
编译环境越简单，理解如何编译源代码所需的时间也就越少。需要多遍编译的编译环境往往都很复杂。在这些多遍编译中，使用不同的编译器标志来编译目标文件，以便解决模块间的互相依赖。第一遍编译一些模块，第二遍可能会编译更多的模块，但是第二次编译使用了前面的编译的结果，以此类推，直到整个编译过程结束。有时候，根据一些非标准的配置文件，编译脚本会调用其他脚本来自动生成一些文件。这些文件的大部分可以和待移植的文件一样看待，但是事实上，这些脚本工具和配置文件才是要移植到目标平台上的内容、这种类型的工具往往会在评估和分析时漏掉了，进而可能会破坏已经制定的进度计划。
源代码控制是另一个必须考虑的。在Linux环境下，Subversion和Git是应用最广泛的源代码控制工具，在一个移植项目中，如果有多个工程师同时来移植相同的模块，那么就需要进行源代码控制。
当从基于x86的Windows平台移植到基于RISC/ARM结构的Linux平台上时，需要检查应用程序对字节序的依赖和字母大小写敏感，例如，为了计算或数据操作而是用了字节交换的应用程序。在没有正确修改字节交换逻辑的情况下，调试问题将变得非常麻烦，因为很难找到数据在哪里出了问题，这主要是因为问题的根源通常是在发生问题的代码之前很远的地方。在调查和分析阶段，一定要找出平台依赖的结构。
硬件依赖的代码
需要内核扩展和设备驱动程序支持的应用程序时最难移植的。所有平台的内核API都不遵循任何标准。因此，API调用、参数个数，甚至是怎样把这些扩展装载到内核，在各个平台上都是不同的。多数情况下，都需要在Linux上开发新的代码。不过有一件事可以肯定，内核代码通常是使用C语言或者平台相关的汇编语言编写的。
移植工作完成以后，如果项目的范围还包括系统测试和验证，测试代码所需要的设备可能也会增加移植的复杂度。如果应用程序需要在复杂的集群或网络环境中测试，设置环境和调配资源也会增加项目的时间。
测试也可能包括性能测试。通常，性能测试都需要运行最大配置，以便检测应用程序在满负载下的运行情况。
移植应用程序测试工具的工作也需要包含在移植进度计划中。需要对包括软件测试和专用硬件配置的测试工具进行评估，以确定其需要多长时间进行移植和配置。
移植用户界面可能很简单，也可能很复杂。基于ASP.NET的用户界面比较容易移植，基于WPF/WinForm技术的用户界面就难以移植了，.NET Core不支持WPF/WinForm。
下面的表总结了需要考虑的各个方面，各个方面都根据其使用的技术列出了难、中、易。
内容 | 容易 | 中等复杂度 | 高复杂度 |
编译器/编程语言 | C#、F# | 使用的语言在.NET Core上支持有限 | 待移植代码的是C++/CLI |
使用第三方产品或中间件 | None | .NET Core上支持的和可用的 | Linux上不支持的； 使用了C++编写的第三方工具 |
编译环境和工具 | Msbuild 脚本 | Msbuild 脚本和编译脚本组合在一起 | |
平台/硬件依赖的代码 | 非平台/硬件依赖的代码 | 平台/硬件依赖的代码来自第三方产品，而且已经移植到了.NET Core | 使用了内核扩展及设备驱动代码 |
测试环境及其搭建 | 独立的 | 客户端/服务器设置 | 网络、高可用行，集群；需要外部设备来测试，如打印机、光纤连接通道磁盘等 |
用户界面 | ASP.NET MVC | ASP.NET WebForm | 不可移植的用户界面，例如WPF |
经验表明，整个移植项目所需的实际工作量，在移植项目开始的前两三周，就可以评估出来。这段时间是待移植代码刚交付给移植项目组，而且移植工程师刚开始熟悉该软件程序，也可能是移植工程师刚开始移植该软件程序。他们开始分解应用程序组件，并搭建最初的编译环境。在最初的两三周内，移植工程师会完成编译环境的配置，并开始编译一些模块。
过了最初的两三周后，最好重新检查原先评估的进度计划，并根据刚得到的实际经验决定是否对计划进行调整。
.NET社区新闻，深度好文，微信中搜索dotNET跨平台或扫描二维码关注