南昌青鳥accp軟件開發(fā)學習

技術是開往創(chuàng)造之美的一次很好的旅行，南昌南航校區(qū)提醒你值得擁有

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

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

本章重點講述軟件移植的詳細過程和技術風險，并列出一些實現(xiàn)高質量應用程序一致的習慣和方法。

軟件程序商業(yè)過程

在開始一個移植項目之前，很重要的一點就是要搞清楚在這個應用程序的生命周期中那些商業(yè)過程會受到影響。那些受到影響的商業(yè)過程必須進行修改，以適應移植后的應用程序，因為需要支持新的平臺、新的測試環(huán)境、新的工具、新的文檔，最重要的是，是需要支持新的客戶并建立客戶關系。

在應用程序的生命周期中，可能會影響到商業(yè)過程的三個主要領域是開發(fā)和測試、客戶支持，以及應用程序發(fā)布：

• 開發(fā)和測試。在開發(fā)和測試部門，必須在以下方面對開發(fā)測試人員進行Linux/Windows技能測試：應用程序編程接口（API）的區(qū)別、開發(fā)工具、調試功能根據(jù)、性能工具，以及待移植的應用程序需要的第三方軟件。

• 客戶支持。在客戶支持部門，必須在以下方面對支持人員進行培訓：Linux/Windows系統(tǒng)管理、移植后的應用程序需要的第三方軟件、安裝和管理方法、Linux/Windows環(huán)境下的包管理工具、調試工具和方法，以及所需要的其他內容。

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

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

移植過程

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

調查

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

• 產品/軟件依賴關系。確定待移植的應用程序所依賴的產品，也就是要確定該應用程序使用那個版本的數(shù)據(jù)庫、中間件以及第三方類庫等。知道了所依賴的產品和版本，移植專家就可以估計在.NET Core平臺上是否有這些產品和版本。

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

• 編譯環(huán)境組件。確定編譯環(huán)境包括確定需要的編譯工具是否在Linux/Windows上可用。對于在源平臺上使用的平臺相關的編譯和鏈接標志必須進行調查，以確定在Linux/Windows上是否存在對應的標志。有些編譯環(huán)境可能依賴于原平臺，這可能要花費較多的功夫才能移植到Linux上。

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

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

• 需要的數(shù)據(jù)庫、中間件和依賴的第三方程序集在.NET Core上不可用。

• 應用程序包括一些需要轉換成Linux匯編指令的匯編例程。

• 應用程序使用了源平臺特有的API或編程模型。這也包括編寫程序時對字母大小寫和字節(jié)序的假設。

• 應用程序時按照.NET的某個版本編寫的，而該標準的實現(xiàn)又依賴于原平臺上特有的編譯器。

• 測試環(huán)境需要復雜的客戶端/服務器架構。

• 開發(fā)環(huán)境需用第三方工具，而該工具需要移植到.NET Core上。

• 應用程序的發(fā)布或安裝需要源平臺的特有的工具。

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

分析

“分析“這一步需要從兩個角度來考慮：項目管理和移植。從項目管理的角度看，分析就是要評估在前一個步驟中確定的各種移植問題和風險，以及它們會對項目移植產生怎么樣的影響?！狈治觥斑@一步要制定項目計劃，包括確定項目的范圍和目標、創(chuàng)建工作進度計劃、獲取資源，以及分配項目角色。

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

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

從移植的角度看，“分析”這一步就是移植工程師詳細地分析應用程序的結構。移植工程師要確定應用程序所使用的API和系統(tǒng)調用，并且評估應用程序使用的動態(tài)鏈接和裝載、網絡、線程等。分析得到這些信息反饋給項目經理，項目經理據(jù)此確定更為詳細的任務，并制定出更為準確的計劃。

移植

“移植“這一步就是移植工程師開始執(zhí)行分配給他們的具體工作。根據(jù)前一步得出的工作細目表，移植工程師可能只能串行的工作。這主要是因為待移植的程序可能是緊耦合的。也就是說，應用程序的一個模塊高度依賴于其他模塊，只有那些被依賴的模塊移植完成后，這些模塊才能開始移植。一個典型的例子就是編譯環(huán)境的移植。如果原來的編譯環(huán)境是設計成一次編譯整個應用程序，那么必須在任何移植工作之前，把各模塊所依賴的通用配置文件修改完畢。

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

在.NET Core上編譯代碼的工作包括確定并消除代碼對體系結構的依賴，以及非標準的編程習慣，包括檢查代碼并使用可移植的數(shù)據(jù)結構或編碼標準。有經驗和質量意識較強的移植工程師會糾正編譯錯誤的同時檢查后者。

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

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

測試

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

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

測試發(fā)現(xiàn)問題后，需要解決這些問題并重新編譯應用程序；然后重新測試該問題，直到應用程序通過所有的測試用例。

支持

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

定義項目范圍和目標

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

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

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

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

下面列出創(chuàng)建項目目標列表時需要遵循的一些基本原則：

1、盡可能詳細定義項目范圍。

2、確認項目的所有相關干系人都同意該項目范圍。

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

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