新注册网站,网站做301排名会掉,wordpress需要mysql,建站宝盒里的手机网站2016年12月1日下午微软技术大会Microsoft Ignite China#xff0c;有幸和大家分享一门课程#xff0c;课程信息如下#xff0c;欢迎大家到时来捧场。本文介绍下应用迁移的风险评估。 很多移植项目超出预算或未能按时完成#xff0c;主要是因为没有很好地管理移植过程中可能… 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 平台上没有可用的第三方产品。在过去的几年中一些中间件厂商例如IBMOracle等都把他们的中间件产品移植到了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 MVCASP.NET WebForm不可移植的用户界面例如WPF 经验表明整个移植项目所需的实际工作量在移植项目开始的前两三周就可以评估出来。这段时间是待移植代码刚交付给移植项目组而且移植工程师刚开始熟悉该软件程序也可能是移植工程师刚开始移植该软件程序。他们开始分解应用程序组件并搭建最初的编译环境。在最初的两三周内移植工程师会完成编译环境的配置并开始编译一些模块。 过了最初的两三周后最好重新检查原先评估的进度计划并根据刚得到的实际经验决定是否对计划进行调整。 .NET社区新闻深度好文微信中搜索dotNET跨平台或扫描二维码关注
