.NET應用遷移到.NET Core（一）

本文介紹下應用遷移的一個過程。

把一個運行在某個作業系統和硬體結構上的軟體，在另一個作業系統和硬體結構上重新編譯（包括一些必要的修改），以便在新的平台上運行，這一過程叫做應用程式移植。有些情況下，把應用程式從一個平台移植到另一個平台非常簡單直接，僅需要重新編譯並進行一些驗證測試即可。但是有些情況下，移植程式並不是那麼容易。

本章是在應用程式移植方面對當前專案管理的一個補充，關於如何使用正規化的需求管理過程、如何更好的與軟體開發人員交流，以及如何進行專案管理，今天的專案經理們都已經非常熟悉了，但是，軟體開發和軟體移植畢竟並不完全相同，這也就是本章要講述的內容。

本章重點講述軟體移植的詳細過程和技術風險，並列出一些實現高品質應用程式一致的習慣和方法。

軟體程式商業過程

在開始一個移植項目之前，很重要的一點就是要搞清楚在這個應用程式的生命週期中那些商業過程會受到影響。那些受到影響的商業過程必須進行修改，以適應移植後的應用程式，因為需要支援新的平台、新的測試環境、新的工具、新的文檔，最重要的是，是需要支援新的客戶並建立客戶關係。

在應用程式的生命週期中，可能會影響到商業過程的三個主要領域是開發與測試、客戶支援，以及應用程式發布：

開發與測試。在開發與測試部門，必須在以下方面對開發測試人員進行Linux/Windows技能測試：API（API）的區別、開發工具、調試功能根據、效能工具，以及待移植的應用程式需要的第三方軟體。

客戶支援。在客戶支援部門，必須在以下方面對技術服務人員進行培訓：Linux/Windows系統管理、移植後的應用程式需要的第三方軟體、安裝和管理方法、Linux/Windows環境下的包管理工具、調試工具和方法，以及所需要的其他內容。

應用程式發布。在應用程式發布部門，必須在Linux/Windows整體特性和知識方面對銷售人員和技術顧問進行培訓。對軟體發布渠道人員，必須對其進行培訓，使其成為Linux/Windows軟體程式的培訓者。從客戶的角度看，他們也希望擷取Linux/Windows整合方面的知識，一併能夠把Linux/Windows和他們已有的IT系統整合在一起。

.NET應用移植應用程式到.NETCore平台，也就意味著修改可能受到新移植的應用程式影響的商業組織過程。應該在真正的移植開始之前，認真考慮這三個主要的方面，並將他們包含在整個移植項目過程中。

移植過程

參與移植項目的開發人員在移植任何項目時都可以遵循類似的步驟。這些步驟包括：調查、分析、移植及測試。過程中的每一步都是後一步的基礎。每一步都做好，後續的步驟也就會很容易完成。

調查

”調查“這一步主要是專案經理召集移植專家（在應用程式方面比較有經驗，並且對開源平台、目標平台及應用程式使用的第三方產品比較瞭解的軟體開發人員）和某一領域內的專家一起來確定待移植的應用程式所依賴的產品、開發與測試環境等。在調查階段要明確的幾個關鍵內容包括：產品/軟體依賴關係、開發環境組件、編譯環境組件和測試環境組件。

產品/軟體依賴關係。確定待移植的應用程式所依賴的產品，也就是要確定該應用程式使用那個版本的資料庫、中介軟體以及第三方類庫等。知道了所依賴的產品和版本，移植專家就可以估計在.NET Core平台上是否有這些產品和版本。

開發環境組件。確定開發環境包括確定待移植的應用程式時用哪種程式設計語言編寫的。使用較新的程式設計語言（例如C#）編寫的應用程式比較容易移植，但是使用C/C++語言編寫的應用程式需要花費較多的時間來分析和移植。

編譯環境組件。確定編譯環境包括確定需要的編譯工具是否在Linux/Windows上可用。對於在源平台上使用的平台相關的編譯和連結標誌必須進行調查，以確定在Linux/Windows上是否存在對應的標誌。有些編譯環境可能依賴於原平台，這可能要花費較多的功夫才能移植到Linux上。

測試環境組件。確定移植後的應用程式所使用的測試環境，會引入一些測試人員應該關注的問題。通常情況下，移植工程師只對他們移植的部分做單元測試，然後就把程式交給測試組來做更完整的驗證和系統測試。但是，誰是測試組呢？

多數情況下，“調查”這一步也會明確一些項目開始後可能遇到的風險。在調查階段可以明確的風險如下：

需要的資料庫、中介軟體和依賴的第三方程式集在.NET Core上不可用。

應用程式套件組合括一些需要轉換成Linux彙編指令的彙編常式。

應用程式使用了源平台特有的API或編程模型。這也包括編寫程式時對字母大小寫和位元組序的假設。

應用程式時按照.NET的某個版本編寫的，而該標準的實現又依賴於原平台上特有的編譯器。

測試環境需要複雜的用戶端/伺服器架構。

開發環境需用第三方工具，而該工具需要移植到.NET Core上。

應用程式的發布或安裝需要源平台的特有的工具。

“調查”這一步需要關注每一個新資訊，這些資訊可以通過問一些問題得到，例如關於文檔、打包、效能調整等的問題。

分析

“分析“這一步需要從兩個角度來考慮：專案管理和移植。從專案管理的角度看，分析就是要評估在前一個步驟中確定的各種移植問題和風險，以及它們會對項目移植產生怎麼樣的影響。”分析“這一步要制定專案計劃，包括確定項目的範圍和目標、建立工作進度計劃、擷取資源，以及分配項目角色。

確定項目的範圍和目標也定義了專案經理和組員的職責範圍和責任。專案範圍指的是項目要完成的一系列工作。例如，像“應用程式ABC的模組A需要移植到平台B上，並在B上測試”，這樣的簡單陳述就是一個很好的定義專案範圍的例子。

專案範圍定義以後，移植工作的具體任務也就是可以定義了，這就產生了一個工作詳細分類的進度表。該進度表可以協助確定哪些工作需要做，以及這些工作是順序做還是可以並行來做。另外，該進度表還列出了所需要的資源。一個完整的進度表可以通過定義專案工作和所需的資源得到。

從移植的角度看，“分析”這一步就是移植工程師詳細地分析應用程式的結構。移植工程師要確定應用程式所使用的API和系統調用，並且評估應用程式使用的動態連結和裝載、網路、線程等。分析得到這些資訊反饋給專案經理，專案經理據此確定更為詳細的任務，並制定出更為準確的計劃。

移植

“移植“這一步就是移植工程師開始執行分配給他們的具體工作。根據前一步得出的工作細目表，移植工程師可能只能串列的工作。這主要是因為待移植的程式可能是緊耦合的。也就是說，應用程式的一個模組高度依賴於其他模組，只有那些被依賴的模組移植完成後，這些模組才能開始移植。一個典型的例子就是編譯環境的移植。如果原來的編譯環境是設計成一次編譯整個應用程式，那麼必須在任何移植工作之前，把各模組所依賴的通用設定檔修改完畢。

如果移植工作相互之間沒有關聯，則移植可以並行進行。松耦合模組的移植可以分開來讓不同的工程師同時進行。一個典型的例子就是共用庫的移植，這樣的共用庫相互之間沒有影響，可以各自獨立編譯，並且只是供其它模組編譯連結使用。確定哪些工作可以並行進行是很重要的，並且這一工作應該是在分析階段完成。

在.NET Core上編譯代碼的工作包括確定並消除代碼對體繫結構的依賴，以及非標準的編程習慣，包括檢查代碼並使用可移植的資料結構或編碼通訊協定。有經驗和品質意識較強的移植工程師會糾正編譯錯誤的同時檢查後者。

移植工作也包括移植編譯環境到Linux/Windows平台。該工作應該在調查階段明確下來。有些編譯環境是可移植的，但有些並不是。確認編譯環境不會導致潛在的問題是很容易被忽略的工作，需要非常仔細的調查和分析。

應用程式移植完成以後（也就是說，在.NET Core上編譯完成了），移植工程師需要對移植的應用程式進行單元測試。單元測試可以很簡單，例如可以簡單的運行程式，看是否產生執行階段錯誤，如果產生執行階段錯誤，就需要在把應用程式交付給測試組以前修改完成這些錯誤。如何，測試組會對程式進行更完全的測試。

測試

在測試過程中，指定的測試人員會對移植後的應用程式運行一些測試案例，這些測試案例都有不同的測試目的，從僅僅運行應用程式的簡單測試到測試應用程式在.NET Core平台上是否足夠健壯的壓力測試。在目標平台上對應用程式進行的壓力測試，可以發現那些除體繫結構依賴和壞的編碼習慣之外的問題。大部分應用程式，尤其是多線程程式，在不同平台上進行壓力測試時，往往會表現出不同的行為，部分原因是因為不同的作業系統實現，尤其是不同的線程的實現。如果在測試過程中發現問題，移植工程師就應該去調試和解決這些問題。

有些應用程式移植也包括移植一套測試載入器來測試該應用程式。移植測試載入器也是應該在調查和測試階段確定的一個任務。多數情況下，測試人員往往需要接受一些對應用程式的培訓，才能測試該應用程式。學習應用程式是一個與移植工作完全獨立的任務，可以與移植任務並行進行。

測試發現問題後，需要解決這些問題並重新編譯應用程式；然後重新測試該問題，直到應用程式通過所有的測試案例。

支援

移植工作完成後，開發階段就算結束了，支援階段也就隨之開始。一些移植工程師會留下來協助回答客戶可能提出一些一直相關的問題。另外，開發人員也應該培訓客戶怎樣在Linux/Windows平台上配置和運行應用程式。在移植結束後，支援階段一般需要持續60到90天。在這期間，針對新移植到.NET Core的應用程式，移植工程師對技術支援人員和銷售人員進行培訓，並回答他們提出的問題。在培訓完成以後，移植工程師的工作就算完成了。

定義專案範圍和目標

定義專案範圍就是定義清楚項目的結束點和邊界，以及專案經理和項目成員的責任。定義清晰的專案範圍可以確保該項目的所有相關者（參與項目或者受項目影響的人員或組織，如項目組、架構師、測試人員、客戶或贊助商、合作部門等）都明確該項目的目標。

清晰的項目目標或需求可以讓人更好地理解專案範圍。在移植過程的分析階段，客戶的目標和需求被收集上來，然後被細分成各個結構，並最終定義成項目的交付物。項目的目標和需求是定義專案範圍的起點。所有的項目目標都確定以後，項目的範圍也就變得更加明確了。

定義專案範圍的一種方法是，列出項目要包含和不包含的目標。從客戶收集需求列表是個很好的開始方法。需求收集上來後，專案經理和技術領導詳細的檢查需求列表。如果對某些需求有疑問，應該把它們列到不被包含的目標列表中，至少最初時應該這樣做。然後客戶再次檢查該列表，並對有異議的地方進行糾正。最後，知道所有人員都認為該列表已經正確表述了項目應該包含的所有目標。

需要再次強調的是，該列表需要足夠詳細，以便能夠列出那些要包含在項目中，那些不要。的確，對超出專案範圍的需求列出詳細說明也是很重要的。對定義專案範圍不能提供足夠資訊的目標，隨著項目發布日期的臨近，會逐漸成為爭論的焦點。例如各個部分移植工作怎樣交付給移植小組---是多次迭代還是一次性交付？每次交付時作為一個階段，還是有一些更小的工作包含在該階段中？在一個完整的項目中有多少個迭代？該列表不僅定義了項目本身，也列出了該項目的所有相關干係人所期望的結果。

下面列出建立項目目標列表時需要遵循的一些基本原則：

1、 儘可能詳細定義專案範圍。

2、 確認項目的所有相關干係人都同意該專案範圍。

3、 在“不包含/不在範圍內”列表中列出未解決的內容，直到全部解決。

定義項目目標的一部分工作是列出項目的接收和完成標準。關於項目的完成標準，所有的項目干係人必須達成一致意見。項目完成可能是指在Linux/Windows平台上通過了百分之多少的系統測試，或者是通過了系統效能所設定的某個效能標準—也就是說，項目目標是運行一組具體的測試案例或者效能分析。不管項目完成的標準是怎樣定義的，如果可能的話，所有的項目干係人在移植開始之前都必須理解並且同意這些標準。任何在移植過程中對標準的修改早替代現有標準前都必須與所有相關干係人交流協商並得到批准。

以上就是.NET應用遷移到.NET Core（一）的內容，更多相關內容請關注topic.alibabacloud.com（www.php.cn）！

