提高 ASP.NET 之可維護性 - 架構設計實務

Herman Wu ( 吳宏彬 )平台架構技術經理台灣微軟

討論內容− 專案維護的挑戰− 程式碼分析− 架構及模型設計

可維護性

「可維護性」與應用程式是否易於修改可說是息息相關。大型應用程式的修改需求會出現在開發時期，而小型應用程式的修改需求則常在交付給客戶之後才發生。以現代的商業處理模式來看，改變是必然而且頻繁的，早期應用程式的維護修改工作只是偶爾為之，現在則是持續不斷地改變，於是「維護」成了應用程式生命週期中的常態，對大型商業系統來說更是如此。

Taco J. Oosterkamp

譯文出自 :http://www.cmlab.csie.ntu.edu.tw/~chenhsiu/docs/MaintainableAppTW.htm

什麼時候會想到可維護性− 當接手別人開發中 / 結束後的專案− 當專案結束三個月後− 當新專案成員加入團隊後− 當客戶要求加入新功能後…− 當專案團隊超過兩個人後… ..

可維護的挑戰− 代價昂貴

− 投注心力− 投注金錢

− 新成員必須花時間瞭解既有系統− 掌握變動系統可能有的風險和影響

可維護性 : 系統架構 x 系統能

見度

能見度 : 了解程式碼狀況− 如何快速了解程式碼架

構與彼此間關連性 ?

− 面對設計變更，如何得知影響程式碼範圍之多寡 ?

− 系統文件是否與程式一致

架構和模型− 決定系統未來的通融能力− 決定系統未來的維護能力− 決定系統未來的執行效能

新舊專案維護的現實與挑戰− 文件的完整程度− 註解的完善程度− 文件和系統之間的同步

− 如何確保開發人員遵循架構要求− 如何確保設計變更是在架構的指導之下− 如何在時程和架構要求之間取得平衡

以工具確保程式碼符合架構− 計畫架構 == 實際架構 ?

− 確保程式碼與架構相符，以減輕維護困難

− 以自動化驗証架構的方式取代傳統 Code Review

Visual Studio 2010 的解答− 事前預防

− 圖層圖 (Layer Diagram)− 程式碼分析 (Code Analysis)

− 事後治療− 架構總管 (Architecture Explorer)− 循序圖 (Sequence Diagram)

− 範例 : Nerddinner http://www.nerddinner.com/

圖層分析及驗證 (Layer Diagram)Before After

設計

驗證

Code review

BL

DA

UITO

VO

Layer Diagram

− 從架構面進行驗證以確保程式碼吻合期望的設計

− 充份呈現期望設計的細節

− 可以在圖中對映類別和命名空間到各個層次

Code Metrics

− 可維護性指數：採用 SEI 發展出來的公式來評估，數值介於 0~9屬於低維護性， 10~19屬於中維護性， 20~100則屬於高維護性

− 循環複雜度：用來評估程式邏輯複雜的程度，像是有使用到 if , while , for 等，點數愈高表示循環複雜度愈高

− 繼承深度：因所有類別至少是繼承 Object Class ，故至少值會是 1 以上，相對的數值愈高，表示繼承關係愈多層，則在找尋定義或是重新調整方法較困難

− 類別結合程度：數值愈高表示類別間相依性愈高，結合程度高表示設計不易重複使用

− 程式碼行數：扣除註解、縮排、宣告等等的行數，所得到的程式碼行數，當然數值愈高，相對後續要維護上較不易，應適當做切割

http://msdn.microsoft.com/zh-tw/library/bb385914(v=vs.90).aspx

Code Analysis

− 有 11 個類別、 200 多項規則

− 以規則為基礎進行分析− 確保程式碼吻合開發原則

−安全議題 (26項 )− 命名原則 (24項 )− 設計 (62項 )− 可靠度 (6項 )− 效能 (17項 )…

Architecture Explorer

− 瞭解系統有助於避免蝴蝶效應 (今日的小變動成為明日臭蟲 )

− 協助發現並理解系統是如何運作的

− 對既有程式碼提供視覺化的資產分析並瞭解其中關聯

架構總管 (Architecture Explorer)Before After

High Level Diagram

Detail Diagram

無法了解物件間的呼叫關係，系統較難維護，新人較難上手。

細部展開

細部檢視

縮短文件與程式碼之間的差距

−動態−視覺化−互動式

程式碼文件

GAP

架構總管(ArchitectureExplorer)

Sequence Diagram

− 以視覺化方式檢視呼叫序列

−省下逐步追查的時間

Q&A