Se ha denunciado esta presentación.
Utilizamos tu perfil de LinkedIn y tus datos de actividad para personalizar los anuncios y mostrarte publicidad más relevante. Puedes cambiar tus preferencias de publicidad en cualquier momento.

你的軟體架構夠敏捷嗎?

914 visualizaciones

Publicado el

Agenda
■ 敏捷一詞,幾乎成為軟體開發領域的罩門
■ 敏捷?是解藥還是毒藥?其實敏捷是有門檻的!
■ 您的軟體架構設計好了?
■ 軟體架構不是設計出來的
■ 軟體『架構設計』與『成本』的關係
■ 常見的軟體設計架構指南
■ Clean Architecture 插件式軟體架構
■ 從 Clean Architecture 來探討什麼是敏捷的軟體架構?
■ 從使用者需求、談架構設計
■ 在 Clean Architecture 裡的 ATDD/TDD?
■ 一個敏捷的軟體架構
■ 在軟體技術市場、需求、市場多變現代你是否覺得疲於奔命?
■ 技術變成速食? 但是沒有辦法被 資源回收再利用~該怎麼辦?

Publicado en: Software
  • Sé el primero en comentar

你的軟體架構夠敏捷嗎?

  1. 1. Gelis 程式設計訓練營 軟體開發之路
  2. 2. 吳俊毅 Gelis - FB 軟體開發之路-經營者 關於我 • 部落格 (Gelis 技術隨筆) http://gelis-dotnet.blogspot.tw/ • FB 粉絲團(Gelis 的程式設計訓練營) https://www.facebook.com/gelis.dev.learning/?ref=bookmarks • FB 社團 (軟體開發之路) https://www.facebook.com/groups/361804473860062/?ref=ts&fref=ts 集英信誠-資深.NET技術顧問
  3. 3. 關於我
  4. 4. 接觸Visual Studio 2002、 WinForm 使用 VB6 做了校務 行政等幾 個專案、 接觸 Delphi 3.0 接觸 Delphi 2.0 實際在專案實作中 使用 ASP.NET、.NET Remoting、 Web Service 撰寫一本 書 Delphi 2005 .NET 程式設計 人生、 工作、 轉淚點 加入緯創 軟體並選 上 Microsoft MVP 轉加入集 英信誠 開始顧問 身涯 集英信誠 與大師 對談 創立Gelis 程式設計 訓練營、 軟體開發 之路 現在 FB 軟體開發之路 (技術分享會) 籌備、發行 更多的 線上課程
  5. 5. 其實,今天是『開發』課程!!!
  6. 6. 敏捷
  7. 7. 0 缺陷的架構? 將所有功能均提供在軟體產品裡,也就是大雜燴的方式, 嘗試滿足市場各種不同的需求
  8. 8. 0 缺陷的架構? 將所有功能均提供在軟體產品裡,也就是大雜燴的方式, 嘗試滿足市場各種不同的需求 (1). 使用單一功能滿足所有企業的使用者難以永久滿足… (因為總是會有需要客製的部分) (2). 功能一定會微調、若為此開立分支(Version Control)將產生另一個災難 (3). 客戶一多,表示你的功能分支越多、這又會產生另一個災難 (4). 軟體架構因為為滿足 A 客戶的某 Function ==> 而導致 B 客戶另一個 Function 失敗 (5). 疊床架屋的軟體終究越來越龐大、每修正一個 Function 或是 擴增一個 Function 都會是一個耗時耗力的過程
  9. 9. 價值 (Value) 架構 (Architecture)
  10. 10. 不良的架構 因為升級替換成本非常巨大 甚至限制住公司的發展
  11. 11. • 可以開發出符合商業需求的軟體? • 可以開發出為客戶創造價值的軟體? • 可以開發出符合市場預期的產品? • 其實軟體公司談敏捷,就是為了『獲利!』
  12. 12. 已經 就要了解所有的需求, 那豈不是代表要先確定 需求?
  13. 13. 已經
  14. 14. 已經
  15. 15. 週期(Cycle)、階段 (phase)、Iteration(迭代) 行 為(activities)、工作流(workflow)、產 品(artifact)、角色(worker)
  16. 16. Jeffrey Palermo
  17. 17. Business Logic INNER
  18. 18. 回歸到最原始的需求面… 你覺得, 你掌握住需求的大方向了嗎? 全貌
  19. 19. 其實、 敏捷是有門檻的!
  20. 20. 武學中”招式”往往最吸引人
  21. 21. 但萬法規宗… 『基礎』才是最重要的!!
  22. 22. Angular CSS DOM JavaScript AJAX/Asynchronous HTML HTTP 外圈才是重要 √ √ √ √ √ √GET POST PUT ...
  23. 23. organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations. UML 創始人之一 Grady Booch: 演化 一部分架構的變 化不會對架構的其它部分產生不必要的負面影響 讓(應用 /功能 functional)的易變部分能夠頻繁地變化, 對 Non-Functional 的影響儘可能地縮小。
  24. 24. Interface
  25. 25. Unit Test 『插件式』軟體架構 - Clean Architecture
  26. 26. UI Iteration 架構可經由迭代不斷演化 • Unit Test
  27. 27. 測試 (Unit Test) • 傳統的瀑布式 Waterfall 為人所詬病的就是,當你確定完 需求、開始做設計,這時候,往往已經過度設計了...
  28. 28. 但沒有確定的(實作/未實作)
  29. 29. (CCP/REP)
  30. 30. 好維護 Refactor 符合客戶所需(價值)
  31. 31. By Donald Firesmith https://insights.sei.cmu.edu/sei_blog/2015/03/four-types-of-shift-left-testing.html
  32. 32. 架構 擴張 擴張 擴張 擴張
  33. 33. 追不上 架構
  34. 34. ATDD Acceptance Testing 共識 目標 期望 (1). Write a failing code (2). Make the Test pass (3). Refactor Domain Model Clean Architecture OOA/OOD Validation Verifies TDD Validate Verification
  35. 35. Domain Service Use Cases Domain Model Service Layer Gateways UI JSON Over (Web API/SignalR) DB ApiHostBase IIS Redis/Cache Socket/ Tcp
  36. 36. • 會使用哪一種 UI? • 會使用哪一種資料庫? • 會運行在 Windows?還 是 Linux? • 誰會存取我?Mobile? Web?Any Devices… • … 不知道 不知道 不知道 不知道
  37. 37. https://www.slideshare.net/GelisWu/code- review-52137113
  38. 38. 延展 性 程式語言 專 案 開 發 易於被使用 (門檻低) 規範 經 驗 中 學 習 信 任 DevOps
  39. 39. 微服務的架構規劃  微服務解決了 SOA 長久一來無法解決的問題  微服務讓傳統企業組織內應用程式充分利用運算資源  微服務做到真正的高可用性  微服務做到最佳化資源使用率  微服務做到降低應用程式與作業環境的依賴性  故障隔離、服務不會因為其中一個服務掛掉而影響其他服務  微服務達到應用程式或服務的快速佈署的目的  自動化佈署 - DevOps 的最佳實踐
  40. 40. 演化 『測試』 【更新/部署】 自動化測試+完整的更新程序 自動化部署 監控系統 DevOps
  41. 41. • 你只要思考: 人為主/工具為本/技術為輔 圖片出處:https://cn.dreamstime.com/%E5%BA%93%E5%AD%98%E7%85%A7%E7%89%87-%E6%B1%BD%E8%BD%A6%E5%B7%A5%E5%85%B7%E7%AE%B1-image43896895
  42. 42. 94
  43. 43. Demo: Project Template 成品演示 1. MyORM Framework 2. EasyArchitect UI
  44. 44. MyORM Framework • EasyArchitect UI Framework
  45. 45. 3) 盡可能落實 Code-Review Check-In Policy 定義 開發的守則 (共同規範) goto (3) 循環 goto (3) 循環

×