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跨平臺或掃描二維碼關注

總結

以上是生活随笔為你收集整理的.NET应用迁移到.NET Core（二）风险评估的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。