1 / 23

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

提高 ASP.NET 之可維護性 - 架構設計實務. Herman Wu ( 吳宏彬 ) 平 台架構技術經 理 台灣微軟. 討論內容. 專案維護的挑戰 程式碼分析 架構及模型設計. 可維護性. 「可維護性」與應用程式是否易於修改可說是息息相關。大型應用程式的修改需求會出現在開發時期，而小型應用程式的修改需求則常在交付給客戶之後才發生。以現代的商業處理模式來看，改變是必然而且頻繁的，早期應用程式的維護修改工作只是偶爾為之，現在則是持續不斷地改變，於是「維護」成了應用程式生命週期中的常態，對大型商業系統來說更是如此。. Taco J. Oosterkamp.

suki
Download Presentation

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

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. 提高ASP.NET 之可維護性 - 架構設計實務 Herman Wu (吳宏彬) 平台架構技術經理 台灣微軟

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

  3. 可維護性

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

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

  6. 可維護的挑戰 • 代價昂貴 • 投注心力 • 投注金錢 • 新成員必須花時間瞭解既有系統 • 掌握變動系統可能有的風險和影響

  7. 可維護性: 系統架構x 系統能見度

  8. 能見度: 了解程式碼狀況 • 如何快速了解程式碼架構與彼此間關連性 ? • 面對設計變更，如何得知影響程式碼範圍之多寡? • 系統文件是否與程式一致

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

  10. 新舊專案維護的現實與挑戰 • 文件的完整程度 • 註解的完善程度 • 文件和系統之間的同步 • 如何確保開發人員遵循架構要求 • 如何確保設計變更是在架構的指導之下 • 如何在時程和架構要求之間取得平衡

  11. 以工具確保程式碼符合架構 • 計畫架構==實際架構? • 確保程式碼與架構相符，以減輕維護困難 • 以自動化驗証架構的方式取代傳統Code Review

  12. Visual Studio 2010的解答 • 事前預防 • 圖層圖(Layer Diagram) • 程式碼分析(Code Analysis) • 事後治療 • 架構總管(Architecture Explorer) • 循序圖(Sequence Diagram) • 範例: Nerddinnerhttp://www.nerddinner.com/

  13. 圖層分析及驗證 (Layer Diagram) UI TO BL VO DA

  14. Layer Diagram • 從架構面進行驗證以確保程式碼吻合期望的設計 • 充份呈現期望設計的細節 • 可以在圖中對映類別和命名空間到各個層次

  15. 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

  16. Code Analysis • 有11個類別、200多項規則 • 以規則為基礎進行分析 • 確保程式碼吻合開發原則 • 安全議題 (26項) • 命名原則(24項) • 設計(62項) • 可靠度(6項) • 效能(17項)…

  17. Architecture Explorer • 瞭解系統有助於避免蝴蝶效應(今日的小變動成為明日臭蟲) • 協助發現並理解系統是如何運作的 • 對既有程式碼提供視覺化的資產分析並瞭解其中關聯

  18. 架構總管 (Architecture Explorer) 細部 展開

  19. 細部檢視

  20. 縮短文件與程式碼之間的差距 動態 視覺化 互動式 架構總管 (Architecture Explorer) GAP 程式碼 文件

  21. Sequence Diagram • 以視覺化方式檢視呼叫序列 • 省下逐步追查的時間

  22. Q&A

More Related