本文介紹下應用遷移的一個過程。
把一個運行在某個作業系統和硬體結構上的軟體，在另一個作業系統和硬體結構上重新編譯（包括一些必要的修改），以便在新的平台上運行，這個過程叫做應用程式移植。有些情況下，把應用程式從一個平台移植到另一個平台非常簡單直接，只需要重新編譯並進行一些驗證測試即可。但是有些情況下，移植程序並不是那麼容易。
本章是在應用程式移植方面對當前專案管理的一個補充，關於如何使用正規化的需求管理過程、如何更好的與軟體開發人員交流，以及如何進行專案管理，今天的專案經理們都已經非常熟悉了，但是，軟體開發和軟體移植畢竟不完全相同，這也就是本章要講述的內容。
本章重點介紹軟體移植的詳細流程和技術風險，並列出一些實現高品質應用程式一致的習慣和方法。
軟體程式商業過程
在開始一個移植專案之前，很重要的一點就是要弄清楚在這個應用程式的生命週期中那些商業過程會受到影響。那些受到影響的商業過程必須進行修改，以適應移植後的應用程序，因為需要支援新的平台、新的測試環境、新的工具、新的文檔，最重要的是，是需要支援新的客戶並建立客戶關係。
在應用程式的生命週期中，可能會影響到商業過程的三個主要領域是開發和測試、客戶支持，以及應用程式發布：
開發和測試。在開發和測試部門，必須在以下方面對開發測試人員進行Linux/Windows技能測試：應用程式介面（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（一）的內容，更多相關內容請關注PHP中文網（www.php.cn）！
