實作開發工作

開發工作是衍生自需求之開發工作的其中一小部分。 將適當的新功能加入至您的軟體，是開發工作實作中的一部分。 開發工作之後，應進行單元測試、檢閱、程式碼分析，然後整合到現有的程式碼基底中。

本主題內容

評估

設計文件

設計檢閱

單元測試

程式碼分析

程式碼檢閱流程

重構

整合變更

評估

評估開發工作的成本，有助於控制功能範圍及排程開發工作。 所有開發工作均應完成成本評估，若有任何問題，均應在反覆項目規劃會議前解決。 如果開發工作的總成本超出反覆項目所能負擔，則必須延後或重新指派工作。 在選擇開發工作後，必須由開發人員評估該項工作的成本。

所選擇的每項開發工作都要建立一個工作工作項目 (Task Work Item)，並連結至據以建立該工作的需求。 若要執行此動作，請使用工作或需求工作項目的 [實作] 索引標籤。 請以完成類似工作所需的時間做為評估基準，並確實將撰寫單元測試的成本納入考量。 請將您對每項工作的評估輸入工作工作項目 (Task Work Item) 的 [原始評估] 欄位中。

工作 (Task) 的工作 (Work) 項目表單會將資料儲存在如下圖所示的欄位和索引標籤中：

在建立並評估工作後，請使用 [工作分工] 查詢檢視您所有需求與工作的進度。 如需詳細資訊，請參閱共用查詢 (CMMI)。

設計文件

您的設計文件應包含足夠的說明資訊，讓開發人員了解如何撰寫用以實作產品需求的程式碼。

設計文件可以是規格、需求工作項目與其他文件的集合，端視您的小組流程而定。

在決定小組的設計時，可以考慮以設計模式、物件導向設計、結構化模型、模組化語言、實體關聯性模型與其他技術做為方針。 將既定關鍵決策的根據納入文件中，也是不錯的作法。 例如，如果成本、排程或技術效能會受到很大的影響，請就造成這些影響的決策，將其制定原因納入文件中，並在您的設計中加入這項資訊。

在建立所需的設計文件後，請將其儲存在可供小組成員共用的位置。 如需詳細資訊，請參閱管理文件和文件庫。

設計檢閱

設計檢閱的用途在於確保新增或修訂的設計在技術上正確無誤、完整、可測試而具有高品質，並且能夠正確實作需求。 設計檢閱是能夠在問題出現於程式碼之前及早發現問題而確保品質的重要方法。 設計檢閱也可提供其他開發人員對於設計的相關觀點。

負責建立設計的開發人員應識別檢閱者、排程檢閱、以及將設計散發給所有檢閱者，以組織設計檢閱。

任何與設計相關或受設計影響的專案關係人，均應參與檢閱。 這通常包括設計區域的專案經理、首席開發人員與測試人員。 與程式碼受檢閱的開發人員同一小組的所有開發人員，均應參與檢閱。

請排程檢閱會議，並及早散發設計文件，讓每位檢閱者有足夠的時間加以閱讀。 請根據所需檢閱的技術性詳細資料數目，為檢閱會議規劃適當的長度。

驗證品質

請確定設計是可測試的。 設計中是否建置了無法以合理方式接受確認或驗證的程式碼？ 若是如此，您將無法確保程式碼的品質，而必須重新設計。 請檢查設計文件中是否含有會導致程式碼錯誤的問題。 同時請查看是否有不正確的介面說明、設計錯誤或不明確的命名。 設計文件應與現有的準則進行比較，例如操作人員介面標準、安全標準、生產條件約束、設計容限或組件標準等。 請建立 Bug 工作項目以說明任何在設計文件中發現的缺陷，並將這些工作項目指派給負責的開發人員。

為設計建立檢閱工作項目

建立檢閱工作項目，可記錄設計檢閱的結果。 檢閱小組必須根據所需的變更幅度，決定設計的後續步驟。 如果無須進行任何變更，則應將工作項目的 [狀態] 設為 [已關閉]、[原因] 設為 [已接受] (維持原狀)，並註明可針對設計開始撰寫程式碼。 如果必須進行次要變更，則應將工作項目的 [狀態] 設為 [已解決]、[原因] 設為 [接受次要變更]。 這表示可以在設計完成次要變更的實作後開始撰寫程式碼。 如果必須進行主要變更，則應將工作項目的 [狀態] 設為 [已解決]、[原因] 設為 [接受主要變更]。 設計必須重新來過，且必須重新執行設計檢閱，才能開始針對設計撰寫程式碼。

單元測試

單元測試會驗證程式碼單元的正確實作。 撰寫和執行單元測試能夠在測試開始之前識別 Bug，也因此能幫助降低品質控制的成本。 在實作開發工作或 Bug 修正時，開發人員必須撰寫所有程式碼的單元測試。 如需詳細資訊，請參閱使用單元測試驗證程式碼。

程式碼分析

程式碼分析會根據有助於強制套用開發方針的規則集，對程式碼進行檢查。 程式碼分析的目的，在於防止程式碼分析違規或警告。 程式碼分析可為您的程式碼檢查超過 200 個有關命名慣例、程式庫設計、當地語系化、安全性與效能的潛在問題。

如果您在開發早期階段就執行程式碼分析，後續階段的違規與警告即可降到最低。

但如果您對先前未檢查過的現有程式碼執行程式碼分析，則可能出現許多違反規則的情形。 若是如此，您可以建立程式碼必須通過的一組基準重要規則，等到較重大的問題解決後，再擴大規則集。 如此可讓小組在改善現有程式碼基底的同時，能夠順利著手處理新功能。

如需詳細資訊，請參閱使用程式碼分析工具進行應用程式品質分析與使用 Team 專案簽入原則強化程式碼品質。

程式碼檢閱流程

首席開發人員應識別檢閱者、排程程式碼檢閱，以及將需要檢閱的程式碼傳送給所有檢閱者，以組織程式碼檢閱。 進行程式碼檢閱的準備工作時，請執行下列步驟：

1. 建立檢閱工作項目，以追蹤檢閱中所做的決策。 如果無須進行任何變更，則應將工作項目的 [狀態] 設為 [已關閉]、[原因] 設為 [已接受] (維持原狀)，並註明可針對設計開始撰寫程式碼。 如果必須進行次要變更，則應將工作項目的 [狀態] 設為 [已解決]，並將 [原因] 設為 [接受次要變更]，這表示可以在實作次要變更後開始撰寫程式嗎。 如果必須進行主要變更，則應將工作項目的 [狀態] 設為 [已解決]、[原因] 設為 [接受主要變更]。 設計必須重新來過，且必須重新執行設計檢閱，才能開始針對設計撰寫程式碼。

2. 決定將參與程式碼檢閱的人員。 一般而言，首席開發人員與負責該程式碼區域的架構設計人員，是必須參與檢閱的基本成員。

3. 排程檢閱者的檢閱會議，並讓每位檢閱者有足夠的時間在會議前閱讀及了解程式碼。 請根據所需檢閱的程式碼數目，為檢閱會議規劃適當的長度。

程式碼檢閱

程式碼檢閱是用來確定新的或已變更的程式碼達到既定的品質門檻，然後才將程式碼整合到每日的組建。 品質考慮事項包括程式碼標準、架構與設計一致性、效能、可讀性以及安全性。 程式碼檢閱也提供從其他開發人員對於程式碼應該如何撰寫的其他深入觀點。

驗證程式碼相關性	接受檢閱的程式碼，與撰寫的程式碼所屬的工作相關連。 任何程式碼變更若無法處理實作或更正的功能，即不被允許。
驗證擴充性	程式碼以適當的方式撰寫而可進行擴充 (若有此用意)，或可在系統的其他區域重複使用。 程式碼中使用的字串常數已正確地納入可國際化的資源中。
驗證最少程式碼的複雜性	重複的程式碼可簡化為通用功能。 類似的功能已納入通用程序或功能中。
驗證演算法複雜性	盡可能減少程式碼中需要檢閱的執行路徑數。
驗證程式碼安全性	對程式碼檢查資產與權限層級的保護性，以及進入點上的資料使用性。

重構程式碼

在程式碼檢閱判定必須進行變更以處理程式碼品質、效能或架構等問題後，程式碼會進行重構。

請閱讀程式碼檢閱工作項目附註，以確認您重構程式碼的方式。

重構應漸次進行，一次執行一個變更。 如有必要，請變更程式碼以及已修改之區域的所有參考。

重構後請執行單元測試，讓該區域在語意上維持不變。 修正任何不成功的單元測試。 執行程式碼分析，若出現警告，請進行修正。 如果在程式碼分析後必須進行程式碼變更，請重新執行單元測試。

整合變更

最後一個步驟是將變更簽入版本控制，加以整合。 您的流程中所必須執行的任何測試，均應在程式碼簽入前執行。 若想進一步了解如何在簽入程式碼前檢查其問題，請參閱使用 Team 專案簽入原則強化程式碼品質。

如果與變更相關聯的工作項目是不屬於您的情節或服務品質需求，請告知其擁有者變更已完成。 請將工作工作項目 (Task Work Item) 設為 [已解決]，並將其指派給其中一個為此工作項目建立測試案例的測試人員。

如果與變更相關聯的工作項目是 Bug，請將 Bug 工作項目設為 [已解決]，並將此工作項目指派給其原始建立者。