Framework Engineering 2.1


Published on

Framework 대가 부분 서두 추가
Team 부분 설명 추가
Breaking Changes 부분 추가

Published in: Technology, Education
1 Like
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Framework Engineering 2.1

  1. 1. Framework EngineeringArchitecting, Designing, and Developing Reusable Libraries <br /><br />
  2. 2. Framework is ..<br />
  3. 3. Framework is…<br />
  4. 4. Douglas C. Schmidt Says..<br />Frameworks define “semi-complete” application<br /> that embody domain-specific object structures and functionality.<br />
  5. 5. Libraries is..<br />Application Block<br />DATABASE<br />ADTs<br />MATH<br />NETWORKING<br />App Specific<br />Logic<br />OO Design<br />Invocations<br />GRAPHICS<br />GUI<br />Event<br />Loop<br />Singleton<br />Strategy<br />Selections<br />Reactor<br />Adapter<br />State<br />Active Object<br />Design Pattern<br />Class Library <br />Component Architecture<br />
  6. 6. But Framework is ..<br />Active Object<br />State<br />NETWORKING<br />GUI<br />Control – Flow (IoC)<br />MATH<br />Reactor<br />Event<br />Loop<br />App Specific<br />Logic<br />Invocations<br />Callbacks<br />ADTs<br />Singleton<br />Adapter<br />DATABASE<br />GRAPHICS<br />Application Framework<br />Component Architecture<br />
  7. 7. Why Do You Need Framework?<br />Productivity<br />Avoid Duplication<br />
  8. 8. Why Do You Need Framework?<br />De Facto War<br />
  9. 9. The Experts of Framework<br />SPLASH (구 OOPSLA ) / PLoP의 창시<br />Gangs of Four 의일원<br />Martin Fowler의 직/간접적 스승<br />Framework 개념의 창시자<br />Designing Reusable Classes<br />Reusing Object-Oriented Design<br />Documenting Frameworks Using Patterns<br />Patterns For Framework Evolution.<br />Ralph Johnson<br />
  10. 10. The Experts of Framework<br />패턴의 중흥기를 이끈 실질적 리더 – <br />PLoP및 PLoPD Editor<br />패턴으로 구축한 프레임워크 공개<br />TAO, ACE등 – 다양한 분야 광범위하게 사용. <br />실제 돌아가는 프레임워크와 패턴을 접목<br />POSA 2, POSA 4, POSA 5권 저자<br /><br />Douglas <br />C. Schmidt <br />
  11. 11. The Experts of Framework<br />Java Platform의 광범위한 부분을<br />설계하고 구현한가장 영향력 있는 리더<br />Sun에서 Google로 Chief Architect로 이직<br />Java에 가장 영향력 있는 둘중에 한 분.<br />How to Design a good api and Why it Matters<br /><br />Joshua<br />Bloch<br />
  12. 12. The Experts of Framework<br />.NET Framework의쌍두마차.<br />Visual C++ 부터 현재 .NET까지 총지휘<br />Brad Abrams는 Google로 2010년 이직<br />KC는 아직 .NET Framework를 진두 지휘<br />실 세계의 Framework 설계 기법 공유 <br />Framework Design Guidelines 1st.<br />Framework Design Guidelines 2nd.<br />Brad Abrams,<br />KrysztofCwalina<br />
  13. 13. Welcome to<br />My Framework<br />Journey!<br />
  14. 14. Seed References<br />“Framework Engineering”, TechED 2007 Europe<br />“Framework Design Guidelines” , Addison Wesley<br />Krzysztof Cwalina<br />Program Manager on .NET Framework Team<br />
  15. 15. 5 Topics..<br />D<br />O<br />P<br />A<br />V<br />
  16. 16. OrganizationThe most powerful design tool<br />O<br />
  17. 17. Project Management Triangle<br />Scope<br />Time<br />Cost<br />O<br />
  18. 18. Organization<br />Project Management Triangle + 1<br />O<br />
  19. 19. Do understand how organizational structure, culture, and decision making processes impact your product. <br />O<br />
  20. 20. Conway's law<br />If you have 4 groups working on a compiler,<br />you’ll get a 4-pass compiler.<br />O<br />
  21. 21. Conway's law<br />O<br />
  22. 22. Conway's Clean State Approach<br />O<br />
  23. 23. Your Company Culture Is ..<br />Voluntary ??<br />O<br />
  24. 24. Your Company Culture Is ..<br />Familial ??<br />O<br />
  25. 25. Remember Your Company Culture ..<br />O<br />Peremptory<br />
  26. 26. Organizational InfluencesSize of Organization<br />Simple Design<br />Consistency Design<br />Focus on 80/20 Rules<br />Small Team<br />O<br />
  27. 27. Organizational InfluencesSize of Organization<br />Powerful Design<br />Lack Consistency<br />Remove Requirements<br />Large Team<br />O<br />
  28. 28. Organizational InfluencesOrganization’s Culture/Biases<br />Customer-Focused<br />End-2-End Scenarios<br />O<br />
  29. 29. Organizational InfluencesOrganization’s Culture/Biases<br />Technology-Focused<br />Long Lasting Architecture<br />O<br />
  30. 30. Decision Making Process is..<br />呼兄呼弟<br />O<br />
  31. 31. Solution ??<br />Give this book your boss..<br />
  32. 32. Planning Ensuring we are building the right thing <br />P<br />
  33. 33. Team Building<br />P<br />
  34. 34. Skyscrapers<br />Peanut Butter<br />Focus: features<br />Results: stability, incremental improvements, not great end-to-end scenarios<br />Focus: scenarios <br />Results: Excitement, breakthroughs, but beware of leaving existing customers behind <br />P<br />
  35. 35. Peanut Butter….<br />
  36. 36. New Requirements Arrive…<br />
  37. 37. Skyscrapers<br />Cross Functional Team<br />
  38. 38.
  39. 39. Cross Functional Teams and Location<br />P<br />
  40. 40. Moderation (中庸)MileStone = Scenarios + Feature<br />Vision statement<br />RTM<br />Feature complete<br />Release<br />Testing<br />Planning<br />M1<br />M2<br />Technology Preview<br />Beta 1<br />Beta 2<br />RC1<br />P<br />
  41. 41. ArchitectureEnsuring the long term health of the framework<br />A<br />
  42. 42. Right Way??Choose right types.<br />A<br />
  43. 43. Taxonomy of TypesLibraries , Primitives, Abstractions<br />A<br />
  44. 44. Primitives<br />Very little policy (behavior design decisions)<br />Stable design<br />Commonly appear in publicly accessible APIs<br />Almost impossible to evolve/change design; <br /> any design changes have huge breaking change impact on other APIs<br />Example: Int32, String<br />A<br />
  45. 45. Libraries<br />Definition:<br />Libraries are types that are not passed <br /> between components<br />Examples<br />EventLog, Debug. <br />Easy to Evolve<br />Leave old in, add new one<br />Beware of duplication!<br />A<br />
  46. 46. Abstractions<br />Definition:<br />Abstractions are interfaces or classes with unsealed members that are passed between components.<br />Examples<br />Stream, IComponent<br />Hard to Evolve<br />Unfortunately, pressure to evolve<br />A<br />
  47. 47. Primitive Oriented Design<br />A.K.A. “Handle based design” (functional)<br />Great evolvability, poor usability (sometimes)<br />Low level stable primitives + high level reusable components with limited dependencies other than to the primitives<br />E.g. Type.GetType(object) – works, but not as convenient as Object.GetType<br />A<br />
  48. 48. Component Oriented Design<br />Rich APIs with lots of features, thus with lots of dependencies<br />Great usability, poor evolvability<br />Good for higher level components, not for the core of a platform<br />A<br />
  49. 49. Do Manage Dependencies..<br />A<br />A<br />
  50. 50. Component is ..<br />Lego, Plug ??<br />A<br />
  51. 51. Component is ..<br />.. a set of types that ship and evolve as a unit.<br />A<br />
  52. 52. Types of Dependencies<br />A<br />
  53. 53. API Dependency<br />Component A has an API dependency on component B, <br /> if a type in B shows in the publicly accessible API surface of a type in A. <br />This includes:<br />Base types and implemented interfaces<br />Generic parameter constraints<br />Return types and parameters of members<br />Applied attributes<br />Nested types<br />A<br />
  54. 54. Implemenatin Dependency<br />If a type in A uses a type in B in its implementation.<br />Hard Dependencies (required to run)<br />Soft Dependencies (optional)<br />A<br />
  55. 55. Circular Dependency<br />Component A depends on component B and<br />Component B depends on component A (even indirectly).<br />A<br />
  56. 56. Solution is Layering..<br />A<br />
  57. 57. Solution is Layering..<br />A<br />
  58. 58. WPF<br />XML<br /><br /><br /><br />BCL<br />Reflection<br />A<br />Dependency Management<br />
  59. 59. 상황을 파악하는 좋은 방법DSM (Dependency Structure Matrix)<br />
  60. 60. 간단한 DSM<br />
  61. 61. 잘 계층화된 DSM<br />
  62. 62. 엄격한 계층화를 유지한 시스템의 DSM<br />
  63. 63. 불완전한 계층구조를 가진 시스템<br />Circular Dependency 발생.<br />
  64. 64. 또 하나의 도구– Code Metrics<br />Demo<br />
  65. 65. Solution is..<br />Create a new package.<br />A<br />
  66. 66. circular dependency<br />GUI<br />Comm<br />Analysis<br />Protocol<br />Modem Control<br />Comm Error<br />Database<br />Message<br />Manager<br />A<br />
  67. 67. Indirect circular dependency<br />A<br />X<br />B<br />Y<br />A<br />
  68. 68. Use Interface.<br />A<br />X<br />Y<br /><<interface>><br />BY<br />B<br />A<br />
  69. 69. Heavy Dependency..<br />A<br />
  70. 70. Solution is IoC<br />A<br />
  71. 71. Heavy Dependency.<br />// your API<br />public class Tracer {<br />MessageQueue mq = new MessageQueue(…);<br /> public void Trace(string message){ <br />mq.Send(message);<br /> }<br />} <br />// your customer’s program that is hard to test<br />Tracer tracer = new Tracer();<br />public void ProcessOrder(Order order){<br /> tracer.Trace(order.Id);<br /> …<br />}<br />A<br />
  72. 72. Inversion of Control<br />// your better API<br />public abstract class TraceListener {<br /> public abstract void Trace(string message);<br />} <br />public class Tracer {<br />TraceListener listener;<br /> public Tracer(TraceListener listener){<br /> this.listener = listener;<br /> }<br /> public void Trace(string message){ <br /> listener.Trace(message);<br /> }<br />} <br />A<br />
  73. 73. Dependency Injection<br />// your customer’s program that is easier to test<br />Tracer tracer = new Tracer(new FileListener());<br />public void ProcessOrder(Order order){<br /> tracer.Trace(order.Id);<br /> …<br />}<br />A<br />
  74. 74. Dependency Injection Containers<br />// customer’s program that is even easier to test<br />Tracer tracer = container.Resolve<Tracer>();<br />public void ProcessOrder(Order order){<br /> tracer.Trace(order.Id);<br /> …<br />}<br />Check outDI Containers (a.k.a. IoC Containers):autofac, Castle Windsor, PicoContainer.NET, Spring.NET, StructureMap, Unity, nInject and others.<br /><br />A<br />
  75. 75. Packaging Principle<br />Package Cohesion Principle<br />REP (Release Reuse Equivalency)<br />CCP (Common Closure Principle)<br />CRP (Common Reuse Principle)<br />Package Coupling Principle<br />ADP (Acyclic Dependencies Principle)<br />SDP (Stable Dependencies Principle)<br />SAP (Stable Abstraction Principle)<br />A<br />Robert C. Martin, Principle of Package Architecture<br /><br />
  76. 76. Do balance advances with compatibility.<br />A<br />
  77. 77. Types of “Compatibility” <br />Backward<br />Cross-Version<br />Forward<br />A<br />
  78. 78. Cross-Redist.<br />A<br />
  79. 79. A<br />
  80. 80. Establishing Compatibility Bar<br />Define what’s a “breaking change”<br />This definition depends on the objective<br />E.g. Enable portable code between Silverlight and .NET Framework<br />E.g. Enable cross-version portability?<br />A<br />
  81. 81. Breaking Changes…<br />Keep Backward Compatibility..<br />
  82. 82. Breaking Changes…<br />신한 은행 ezPlus<br />Quiz - ezPlus의 버전은??<br />
  83. 83. Breaking Changes…<br />MS 직원과의 대화 <br />MS에서 새 API 추가와 기존 API 변경에 들이는 시간과 노력을 아시면 절대 그렇게 말하지 못할 것.<br />중첩된 역할을 가진 API들이 많아지게 됨.<br />비동기메소드<br />DownloadAync, InvokeAsync, DownloadTaskAsync <br />동일한 역할을 하는 API들이 계속 늘어남..<br />Java의 NewIO와 IO도 동일한 상황.<br />대형 밴더들은 호환성은 가상화로 대체하자는 추세임.<br />
  84. 84. Breaking Changes…<br />MS에서 유일하게 <br /> Backward Compatibility를 무시해도 되는 경우가 있음.<br />Quiz – 무엇일까요?<br />
  85. 85. Breaking Changes…<br />새 술은 새 부대에..<br />Apple/Android는 과감히 쓸모없는 것을 버리는 전략.<br />새로운 기술과 경험이 들어감에 따라 API를 Refactoring하고 Cleanup해야 점점 사용해지기 쉬워져야 된다.<br />단편화 문제가 발생함.<br />
  86. 86. Breaking Changes…<br />MS의 눈물겨운 Backward Compatibility 이야기.<br /><br />
  87. 87. Breaking Changes.<br />.NET Framework Breaking Changes.<br />.NET Framework 4.0 (3.5 -> 4.0)<br /><br />.NET Framework 3.5 (2.0 -> 3.5)<br /><br />.NET Framework 2.0 (1.0 -> 2.0)<br /><br />기업에서 .NET 4.0으로 못 갈 정도로 큰 변화.<br />민감한 Active X 문제 -<br />(SmartClient를 실행시키는 IEHost.exe 제거)<br />
  88. 88. Avoid duplication and overlap.<br />A<br />
  89. 89. Team Space<br />Show and Tell<br />Problem Space<br />PLoP – Capable, Productive and Satisfied Patterns for Productivity<br /><br />A<br />
  90. 90. When to Replace Existing APIs<br />When the new technology is “10x better”<br />Make sure you understand the impact on the ecosystem<br />What would happen if the BCL team added a new String?<br />What’s the migration path for code using the old API?<br />Support Automatic Migration Tool. <br />(VB -> VB.NET, .NET 1.0 -> .NET 2.0)<br />Provide Code Based Migration Manual. <br />COM+ -> WCF , ASP.NET Web Service -> WCF<br />A<br />
  91. 91. DesignThis is where quality happens<br />D<br />
  92. 92. Is using your framework correctly like…<br />Running across a desert?<br />D<br />
  93. 93. You need Feedback.<br />D<br />
  94. 94. Do design APIs by <br /> first writing code samples for the main scenarios <br /> and then <br />defining the object model to support the code samples.<br />D<br />
  95. 95. Code Samples<br />D<br />
  96. 96. Read File<br />static void Main(string[] args)<br />{<br />StreamReadersr = File.OpenText("MyFile.txt");<br /> string s = sr.ReadLine();<br /> while (s != null)<br />{<br /> s = sr.ReadLine();<br />Console.WriteLine(s);<br />}<br />}<br />D<br />
  97. 97. Feedback (Read File)<br />static void Main(string[] args)<br />{<br />foreach (string s in File.ReadAllLines("MyFiles.text"))<br /> {<br />Console.WriteLine(s);<br />}<br />}<br />D<br />
  98. 98. Object Model Listing<br />D<br />
  99. 99. Framework Design Studio Assembly Exploer<br />Project -> Add -> Assembly<br />D<br />Download here -<br />
  100. 100. Framework Design Studio Assembly Review Comment<br />D<br />
  101. 101. Framework Design StudioCompare API Versions<br />D<br />
  102. 102. Framework Design StudioCompare API Versions<br />Red is removed, <br />Green is added,<br />Grey means inherited.<br />D<br />
  103. 103. Framework Design StudioExporting to Microsoft Word<br />Tools -> Export to Document<br />D<br />
  104. 104. Do treat simplicity as a feature.<br />D<br />
  105. 105. KISS (Keep It Simple! Stupid!)<br />Remove Requirements<br />Reuse Existing Concepts or APIs.<br />Adjust Abstraction Level <br />Consider framework users(experience, knowledge)<br />Three Example<br />D<br />
  106. 106. Domeasure, measure, and measure!<br />D<br />
  107. 107. Specification Document: Qualities<br />Performance Goals (XML Parser..)<br />Baseline: What do is the best my API could do?<br />Measure delta from the baseline<br />Threat Models (Security ..)<br />Threat: What is the worst that my component could do?<br />Mitigate the threats<br />Keep a balance between many other qualities you want your framework to have (ATAM)<br />D<br />
  108. 108.  The POWER oFSameness<br />D<br />
  109. 109. Read the manual??<br />When you pick up your rental car….<br />Push the seat all the way back<br />Find an NPR station<br />Find the exit<br />D<br />
  110. 110. Oh, down to lock…<br />D<br />
  111. 111. How to use a key…<br />D<br />
  112. 112. Oh, you push the PRESS button…<br />D<br />
  113. 113. Who actually needs this data?<br />D<br />
  114. 114. Why you don’t read manuals ???<br />You know how to drive your car<br />All cars work basically the same way<br />Your rental car is a car<br />Therefore, you can drive your rental car<br />That is…<br />The power of sameness<br />D<br />
  115. 115. Static Analysis Tool <br /><br />D<br />
  116. 116. DevelopmentThe bits customers get, … or not<br />V<br />
  117. 117. Branches and Integrations- Feature Crew<br /><br />V<br />
  118. 118. Avoid integrating unfinished features.<br />V<br />
  119. 119. Feature Complete & Quality Gates<br />Functional Specification<br />Developer Design Specification<br />Test Plan<br />Threat Model<br />API review<br />Architectural Review<br />Dependency Management<br />Static Analysis<br />Code Coverage<br />Testing (Unit and Integration Tests)<br />0 Bugs<br />Performance <br />V<br />
  120. 120. Do pay your debt.<br />V<br />
  121. 121. Milestone Quality<br />Vision statement<br />RTM<br />Feature complete<br />Release<br />Testing<br />Planning<br />M1<br />M2<br />Technology Preview<br />Beta 1<br />Beta 2<br />RC1<br />Milestone Quality<br />V<br />
  122. 122. Milestone Quality (MQ)<br />Initiatives that are hard to do in regular milestones<br />Large productivity and efficiency improvements<br />Infrastructure changes<br />For example, a new source control system <br />Refactoring of fragile subsystems<br />Internal implementation documentation<br />Bugs backlog<br />V<br />
  123. 123. Summary<br />Dounderstand how organizational structure, culture, and decision making processes impact your product. <br />Avoidpeanut-butter in Scenario Based Application.<br />Domanage your dependencies.<br />Dobalance advances with compatibility.<br />Avoidduplication and overlap.<br />Do design APIs by first writing code samples for the main scenarios and then defining the object model to support the code samples.<br />Do treat simplicity as a feature.<br />Domeasure, measure, and measure!<br />Avoidintegrating unfinished features.<br />Do pay your debt.<br />
  124. 124. Resources<br />Krzysztof Cwalina, Brad Abrams<br />Framework Design Guidelines:<br />Conventions, Idioms, and Patterns for Reusable .NET Libraries<br /><br /><br />
  125. 125. Resources<br />Douglas C. Schmidt (PLoP Editor, POSA 2, 4 Writter)<br />JAWS: An Application Framework for High Performance Web System<br /> (En)<br /> (Kr)<br />Ralph Johnson (GoF , Design Patterns)<br />Evolving Frameworks<br /> (En)<br /> (Kr)<br />
  126. 126. Resources<br />Robert C. Martin<br />Principles of Package Architecture (Design Principles and Design Patterns)<br /> (En) <br /> (Kr)<br />For Korean People..<br />Load to Architect<br /><br />EvaCast (Online Free Lecture)<br /><br />
  127. 127. 최근 저서 및 곧 나올 저서..<br />
  128. 128. 곧 나올 저서..<br />
  129. 129. Question?<br />이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 <br />대한민국 라이센스에 따라 이용하실 수 있습니다. <br />This work is licensed under Creative Commons Korea Attribution 2.0 License.<br />