Architecture In The Small
5 likes645 views
The document discusses the role of architects in software development, emphasizing the importance of communication and technical leadership in achieving design goals. It identifies common project failure causes related to architecture, such as unrealistic goals and poor communication, and suggests that architects should actively code to demonstrate and validate design choices. Key takeaways include creating clean, maintainable code and avoiding complexity while addressing essential software qualities like usability and scalability.
![[Serializable][AttributeUsage(AttributeTargets.Assembly | AttributeTargets.Class, AllowMultiple = false, Inherited = false)][MulticastAttributeUsage(MulticastTargets.Class, AllowMultiple = false)]publicclassNotifyPropertyChangedAttribute : CompoundAspect{publicintAspectPriority { get; set; }publicoverridevoidProvideAspects(object element, LaosReflectionAspectCollection collection){Typetype = (Type)element;collection.AddAspect(type, newPropertyChangedAspect { AspectPriority = AspectPriority });foreach (PropertyInfopropertyInfointype.GetProperties(BindingFlags.Public | BindingFlags.Instance) .Where(pi => pi.GetGetMethod() != null && pi.GetSetMethod() != null)) {collection.AddAspect(propertyInfo.GetSetMethod(),newNotifyPropertyChangedAspect(propertyInfo.Name, propertyInfo.PropertyType,propertyInfo.DeclaringType) { AspectPriority = AspectPriority }); } }}](https://image.slidesharecdn.com/architectureinthesmall-091022161151-phpapp01/85/Architecture-In-The-Small-44-320.jpg)
Architecture In The Small
- 1. Architecture In the SmallRichard BanksPrincipal Consultant, ReadifySydney & Virtual ALT.NET Groupshttp://richardsbraindump.blogspot.comrichard.banks@readify.nethttp://twitter.com/rbanks54
- 2. What Does an Architect do?
- 5. Explain how to “Get There”™
- 6. Lead the Way Technically
- 8. The Design & Structure
- 12. Simple, Right?
- 13. NSW Transit T-Card$370million10 years0 to show
- 14. Westpac Rebuild (1988)$156 million3 years0 to show
- 15. Not just big projects
- 16. Apps that can’t support 10 users
- 17. Apps that lose/corrupt data
- 18. Apps that are
- 19. So where does it go wrong?
- 20. Project Failure ReasonsArchitect Involvement Has Yellow Background
- 21. Unrealistic or unarticulated goals
- 23. Badly defined system requirements
- 24. Poor reporting of the project's status
- 25. Unmanaged risks
- 26. Poor communication among customers, developers, and users
- 27. Use of immature technology
- 28. Inability to handle the project's complexityand Over Complexificationisationing
- 33. Another Issue...
- 34. Software Is Designed Top Down
- 41. Software is Built Bottom Up
- 44. [Serializable][AttributeUsage(AttributeTargets.Assembly | AttributeTargets.Class, AllowMultiple = false, Inherited = false)][MulticastAttributeUsage(MulticastTargets.Class, AllowMultiple = false)]publicclassNotifyPropertyChangedAttribute : CompoundAspect{publicintAspectPriority { get; set; }publicoverridevoidProvideAspects(object element, LaosReflectionAspectCollection collection){Typetype = (Type)element;collection.AddAspect(type, newPropertyChangedAspect { AspectPriority = AspectPriority });foreach (PropertyInfopropertyInfointype.GetProperties(BindingFlags.Public | BindingFlags.Instance) .Where(pi => pi.GetGetMethod() != null && pi.GetSetMethod() != null)) {collection.AddAspect(propertyInfo.GetSetMethod(),newNotifyPropertyChangedAspect(propertyInfo.Name, propertyInfo.PropertyType,propertyInfo.DeclaringType) { AspectPriority = AspectPriority }); } }}
- 45. Design == WhatCode == How
- 46. There’s a Disconnect Here
- 47. It’s the Architect’s Problem
- 48. Solution:
- 49. Design & Architect codeat the Lowest Levels toSupport High Level design goals
- 50. Architecture in the Small
- 51. Deals with (at least) 3 Failure Causes
- 53. Where Architects Go Wrong
- 54. Stopping Short on Design
- 57. Following Guidance without Thinking(P&P)
- 59. N.I.H. Syndrome
- 60. Not (properly) Explaining Howthings should be done
- 61. Not Trying Out What They Expect Others To Do
- 62. a.k.a.One-Directional ArchitectureOnly doing Top Down Design
- 63. Remember:The only way to “Get There” is via code
- 65. If you code it you can explain it
- 67. Ensure Guidance Makes Sense
- 68. Provide Examples Others Can Follow
- 69. Deal With Technical Risk
- 70. Find Problems You Overlooked
- 71. Example: AOP
- 72. Choice of MethodsIL WeavingInterceptorsRoll your own
- 73. Choice of ToolsEntLibIoC ContainerPostSharp...more
- 74. Impact on compile times
- 77. Impact on runtime performance
- 79. If you’ve never tried it...How will you prove it works?How will you show others?
- 80. Another Thing to Consider
- 81. Teams mimic their architect
- 82. Write Clean, Maintainable Code
- 83. Example Time
- 87. Worst Method?
- 88. CC: 81LOC: 282Coupling: 32
- 89. Complexity FAIL!
- 90. Lesson: Keep Code SimpleBut don’t be simplistic
- 91. Lesson: Small Methods Only20 Lines or Less
- 97. Lesson: Use Domain Language
- 103. Lesson: Single Level Of Abstraction
- 105. Lesson: Avoid the “Duh!”Experience: Captain Obvious comments indicate a poorly architected system
- 106. A Note on Unit Testing
- 107. Test Code == Production Code
- 110. Lesson: Name Tests Well
- 114. Lesson: Test Behaviour Not State
- 115. Lesson: Test Just One Behaviour
- 116. What About the *ilities
- 118. Maintainability:Destroyed in the smallIncludes agility, flexibility, testability, etc
- 119. Scalability:Hampered by the small
- 120. Reliability:Brought down by the small
- 121. Extensibility:Stymied by the small
- 122. Securability:Foiled via the small
- 123. Performance:Stalled by the small
- 124. It all comes from what happens in the small
- 125. Recap
- 126. Architects Are Project Fail Points
- 127. Architects Need to Code
- 128. Prove The Design
- 129. Lead By Example
- 131. Simple but Not Simplistic Code
- 132. Communicate via Code(not just Diagrams)
- 133. And sweat the details!
Editor's Notes
- #2: Introduction slide: this slide must be the first slide in every RDN deck. Update the following:Title of TalkPresenter NamePresenter Position