2016年12月1日下午微軟技術(shù)大會(huì)Microsoft Ignite China，有幸和大家分享一門課程，課程信息如下，歡迎大家到時(shí)來(lái)捧場(chǎng)。本文介紹下應(yīng)用遷移的風(fēng)險(xiǎn)評(píng)估。

很多移植項(xiàng)目超出預(yù)算或未能按時(shí)完成，主要是因?yàn)闆](méi)有很好地管理移植過(guò)程中可能遇到的風(fēng)險(xiǎn)。風(fēng)險(xiǎn)是在估計(jì)進(jìn)度和資源時(shí)要考慮的一個(gè)重要因素。在應(yīng)用程序移植項(xiàng)目中，這些風(fēng)險(xiǎn)來(lái)自與移植相關(guān)的不同方面，主要包括下面幾種：

• 移植工程師的技能水平和移植經(jīng)驗(yàn)。

• 使用的編譯器。

• 使用的編程語(yǔ)言。

• 第三方軟件和中間件的可用性。

• 編譯環(huán)境和工具。

• 平臺(tái)依賴的結(jié)構(gòu)。

• 平臺(tái)和硬件依賴的代碼。

• 需要搭建的測(cè)試環(huán)境。

• 用戶界面需求。

依賴于要移植的具體應(yīng)用程序，以上各個(gè)方面的每一個(gè)都可能給移植項(xiàng)目帶來(lái)不同的復(fù)雜度和風(fēng)險(xiǎn)。評(píng)估這些復(fù)雜度和風(fēng)險(xiǎn)的級(jí)別，可以幫助你確定它們是不是可管理的。

技能水平和移植經(jīng)驗(yàn)

???????? 應(yīng)用程序移植和軟件開(kāi)發(fā)最明顯的區(qū)別就是編程人員所掌握的技能。雖然軟件開(kāi)發(fā)人員往往是某一領(lǐng)域內(nèi)比較專業(yè)的人員，但是要做軟件移植的開(kāi)發(fā)人員卻需要更寬廣的知識(shí)和技能。一個(gè)應(yīng)用程序開(kāi)發(fā)人員可以是Windows開(kāi)發(fā)環(huán)境上的.NET專家，或者是Windows操作系統(tǒng)上SQL Server的數(shù)據(jù)庫(kù)專業(yè)開(kāi)發(fā)人員；但是，從事代碼移植工作的工程師卻通常需要時(shí)兩個(gè)或者更多操作系統(tǒng)、編程語(yǔ)言、編譯器、調(diào)試器、數(shù)據(jù)庫(kù)、中間件或最新的基于網(wǎng)頁(yè)的技術(shù)方面的專家。他們還需要知道怎樣安裝和配置第三方數(shù)據(jù)庫(kù)或中間件。

???????? 應(yīng)用程序開(kāi)發(fā)人員需要的往往是專才，而移植工程師則多是通才。應(yīng)用程序開(kāi)發(fā)人員可以為一個(gè)軟件工作18個(gè)月，但是移植工程師在一個(gè)項(xiàng)目上往往只需要工作3~6個(gè)月，并且在上一個(gè)項(xiàng)目完成以后，即可投入下一個(gè)新的移植項(xiàng)目中。為一個(gè)移植項(xiàng)目找到完全適合的移植工程師有時(shí)候是很困難的，從老的技術(shù)移植到新的技術(shù)上時(shí)尤其如此。

編譯器

???????? 在Windows平臺(tái)上使用的編譯器和編譯器框架，與Linux平臺(tái)上使用的有很大不同。如果在Windows平臺(tái)和Linux平臺(tái)上使用的是相同的編譯器，移植工作將會(huì)變得容易一些，例如在兩個(gè)平臺(tái)上都是用的是GNU編譯器，除了-g和-c標(biāo)志外，不同的編譯器使用的編譯器標(biāo)志可能大不相同，尤其是應(yīng)用程序使用C++語(yǔ)言的時(shí)候。

???????? 另外一個(gè)需要考慮的事情是編譯器的版本。要移植的代碼可能是幾年前使用老版本的編譯器編譯的，這些代碼可能使用了與新的編譯器不同的語(yǔ)法，這就使得在不同的編譯器上移植程序比較困難，因?yàn)檫@些編譯器可能支持也可能不支持老的標(biāo)準(zhǔn)，即使新的編譯器支持老的標(biāo)準(zhǔn)，不同編譯器對(duì)這些標(biāo)準(zhǔn)的支持方式也可能不太相同。

.NET Core項(xiàng)目的C# 編譯器的實(shí)現(xiàn)非常完整，和.NET編譯器實(shí)現(xiàn)遵循同樣的ECMA標(biāo)準(zhǔn)的“Roslyn”新編譯器，大大降低了移植.NET項(xiàng)目的難度。

第三方軟件和中間件的可用性

???????? 當(dāng)待移植的應(yīng)用程序使用了第三方軟件或中間件時(shí)，移植的復(fù)雜度會(huì)隨之增加，尤其是在目標(biāo)平臺(tái)上沒(méi)有這些第三方產(chǎn)品時(shí)，移植的難度會(huì)更大。可能會(huì)出現(xiàn)在Linux 平臺(tái)上沒(méi)有可用的第三方產(chǎn)品。在過(guò)去的幾年中，一些中間件廠商，例如IBM，Oracle等都把他們的中間件產(chǎn)品移植到了Linux上。他們花了一些功夫，使那些已經(jīng)使用或者準(zhǔn)備使用Linux作為企業(yè)平臺(tái)的公司在Linux上可以使用它們的中間件產(chǎn)品。這也是為什么越來(lái)越多的公司愿意把應(yīng)用程序從Windows移植到Linux上的部分原因。

編譯環(huán)境和工具

???????? 編譯環(huán)境越簡(jiǎn)單，理解如何編譯源代碼所需的時(shí)間也就越少。需要多遍編譯的編譯環(huán)境往往都很復(fù)雜。在這些多遍編譯中，使用不同的編譯器標(biāo)志來(lái)編譯目標(biāo)文件，以便解決模塊間的互相依賴。第一遍編譯一些模塊，第二遍可能會(huì)編譯更多的模塊，但是第二次編譯使用了前面的編譯的結(jié)果，以此類推，直到整個(gè)編譯過(guò)程結(jié)束。有時(shí)候，根據(jù)一些非標(biāo)準(zhǔn)的配置文件，編譯腳本會(huì)調(diào)用其他腳本來(lái)自動(dòng)生成一些文件。這些文件的大部分可以和待移植的文件一樣看待，但是事實(shí)上，這些腳本工具和配置文件才是要移植到目標(biāo)平臺(tái)上的內(nèi)容、這種類型的工具往往會(huì)在評(píng)估和分析時(shí)漏掉了，進(jìn)而可能會(huì)破壞已經(jīng)制定的進(jìn)度計(jì)劃。

???????? 源代碼控制是另一個(gè)必須考慮的。在Linux環(huán)境下，Subversion和Git是應(yīng)用最廣泛的源代碼控制工具，在一個(gè)移植項(xiàng)目中，如果有多個(gè)工程師同時(shí)來(lái)移植相同的模塊，那么就需要進(jìn)行源代碼控制。

平臺(tái)依賴的結(jié)構(gòu)

???????? 當(dāng)從基于x86的Windows平臺(tái)移植到基于RISC/ARM結(jié)構(gòu)的Linux平臺(tái)上時(shí)，需要檢查應(yīng)用程序?qū)ψ止?jié)序的依賴和字母大小寫敏感，例如，為了計(jì)算或數(shù)據(jù)操作而是用了字節(jié)交換的應(yīng)用程序。在沒(méi)有正確修改字節(jié)交換邏輯的情況下，調(diào)試問(wèn)題將變得非常麻煩，因?yàn)楹茈y找到數(shù)據(jù)在哪里出了問(wèn)題，這主要是因?yàn)閱?wèn)題的根源通常是在發(fā)生問(wèn)題的代碼之前很遠(yuǎn)的地方。在調(diào)查和分析階段，一定要找出平臺(tái)依賴的結(jié)構(gòu)。

平臺(tái)/硬件依賴的代碼

???????? 需要內(nèi)核擴(kuò)展和設(shè)備驅(qū)動(dòng)程序支持的應(yīng)用程序時(shí)最難移植的。所有平臺(tái)的內(nèi)核API都不遵循任何標(biāo)準(zhǔn)。因此，API調(diào)用、參數(shù)個(gè)數(shù)，甚至是怎樣把這些擴(kuò)展裝載到內(nèi)核，在各個(gè)平臺(tái)上都是不同的。多數(shù)情況下，都需要在Linux上開(kāi)發(fā)新的代碼。不過(guò)有一件事可以肯定，內(nèi)核代碼通常是使用C語(yǔ)言或者平臺(tái)相關(guān)的匯編語(yǔ)言編寫的。

搭建測(cè)試環(huán)境

???????? 移植工作完成以后，如果項(xiàng)目的范圍還包括系統(tǒng)測(cè)試和驗(yàn)證，測(cè)試代碼所需要的設(shè)備可能也會(huì)增加移植的復(fù)雜度。如果應(yīng)用程序需要在復(fù)雜的集群或網(wǎng)絡(luò)環(huán)境中測(cè)試，設(shè)置環(huán)境和調(diào)配資源也會(huì)增加項(xiàng)目的時(shí)間。

???????? 測(cè)試也可能包括性能測(cè)試。通常，性能測(cè)試都需要運(yùn)行最大配置，以便檢測(cè)應(yīng)用程序在滿負(fù)載下的運(yùn)行情況。

???????? 移植應(yīng)用程序測(cè)試工具的工作也需要包含在移植進(jìn)度計(jì)劃中。需要對(duì)包括軟件測(cè)試和專用硬件配置的測(cè)試工具進(jìn)行評(píng)估，以確定其需要多長(zhǎng)時(shí)間進(jìn)行移植和配置。

用戶界面需求

???????? 移植用戶界面可能很簡(jiǎn)單，也可能很復(fù)雜。基于ASP.NET的用戶界面比較容易移植，基于WPF/WinForm技術(shù)的用戶界面就難以移植了，.NET Core不支持WPF/WinForm。

?

下面的表總結(jié)了需要考慮的各個(gè)方面，各個(gè)方面都根據(jù)其使用的技術(shù)列出了難、中、易。

?

內(nèi)容	容易	中等復(fù)雜度	高復(fù)雜度
編譯器/編程語(yǔ)言	C#、F#	使用的語(yǔ)言在.NET Core上支持有限	待移植代碼的是C++/CLI
使用第三方產(chǎn)品或中間件	None	.NET Core上支持的和可用的	Linux上不支持的； 使用了C++編寫的第三方工具
編譯環(huán)境和工具	Msbuild 腳本	Msbuild 腳本和編譯腳本組合在一起
平臺(tái)/硬件依賴的代碼	非平臺(tái)/硬件依賴的代碼	平臺(tái)/硬件依賴的代碼來(lái)自第三方產(chǎn)品，而且已經(jīng)移植到了.NET Core	使用了內(nèi)核擴(kuò)展及設(shè)備驅(qū)動(dòng)代碼
測(cè)試環(huán)境及其搭建	獨(dú)立的	客戶端/服務(wù)器設(shè)置	網(wǎng)絡(luò)、高可用行，集群；需要外部設(shè)備來(lái)測(cè)試，如打印機(jī)、光纖連接通道磁盤等
用戶界面	ASP.NET MVC	ASP.NET WebForm	不可移植的用戶界面，例如WPF

???????? 經(jīng)驗(yàn)表明，整個(gè)移植項(xiàng)目所需的實(shí)際工作量，在移植項(xiàng)目開(kāi)始的前兩三周，就可以評(píng)估出來(lái)。這段時(shí)間是待移植代碼剛交付給移植項(xiàng)目組，而且移植工程師剛開(kāi)始熟悉該軟件程序，也可能是移植工程師剛開(kāi)始移植該軟件程序。他們開(kāi)始分解應(yīng)用程序組件，并搭建最初的編譯環(huán)境。在最初的兩三周內(nèi)，移植工程師會(huì)完成編譯環(huán)境的配置，并開(kāi)始編譯一些模塊。

???????? 過(guò)了最初的兩三周后，最好重新檢查原先評(píng)估的進(jìn)度計(jì)劃，并根據(jù)剛得到的實(shí)際經(jīng)驗(yàn)決定是否對(duì)計(jì)劃進(jìn)行調(diào)整。

---

.NET社區(qū)新聞，深度好文，微信中搜索dotNET跨平臺(tái)或掃描二維碼關(guān)注

總結(jié)

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

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。