Notes on architecture

2,165 views

Published on

Published in: Technology, News & Politics
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
2,165
On SlideShare
0
From Embeds
0
Number of Embeds
27
Actions
Shares
0
Downloads
250
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Notes on architecture

  1. 1. Notes on Architecture Dr. Joonas Lehtinen Founder & CEO / Vaadin
  2. 2. Structure [only] when needed
  3. 3. Nightmare
  4. 4. Dream
  5. 5. Last name varchar: ! LAST_NAME
  6. 6. Software architecture danger #1 Prepares for expansion and changes that will never happen Overdesigned architecture Tries to achieve faulttolerance or scalability never needed Increases risks by making implementation complex
  7. 7. If you are not 100% sure that a requirement is solid, choose a simpler structure even when the requirement night not be fulfilled
  8. 8. All requirements having an impact on architecture must have clear metrics and goals
  9. 9. Learn to estimate and communicate cost impacts to negotiate requirements
  10. 10. Overgeneralization
  11. 11. Customization by Programming Card UI Example System Integration Example DataSource Example Custom Card UI External System Custom DataSource Web Browser Customization by Configuring Millstone Cards 2.0 Settings (XML) Theme (HTML, CSS, ...) SQL DB Report (XSL) External Reporting System Settings Example Theme Example Report Example
  12. 12. Software architecture danger #2 Claims that your software can do thinks that you do not know Overgeneralization Moves the unknown to layers where it should not be (UI or user) Tries to overcome unknown requirements
  13. 13. Decoupling tries to reduce complexity by adding complexity
  14. 14. You are now do prepared to I really change a need to meatball change it?
  15. 15. Two edged sword of software architecture Can make your system easier to understand (modules decoupled) De-coupling Can make your system harder to understand (more modules and interfaces) Will make your system slower to build, but could make it easier to maintain
  16. 16. Decouple only things that should be built separately. ! Decouple for readability, not for potential change.
  17. 17. For the love of Refactoring
  18. 18. Refactoring is very cheap. Rewriting (working parts) is cheaper than you think. Cleaning up the mess late never happens. Keep your room tidy!
  19. 19. #1 Choose a statically typed language or loose refactoring tooling support
  20. 20. Start with the simplest possible architecture. ! When you realize you need to work around your own architecture to add features, or it is impossible to add new features, or you don't know how to model your new features on top of the architecture refactor! - Petter Holmström
  21. 21. Art of naming
  22. 22. One of the hardest tasks Critical for clarity Naming Takes a lot of time when done properly Should be debated in code review Sign of a good architecture
  23. 23. Follows project style Short Documents the described thing Good name Intuitive Unique (for project and domain)
  24. 24. Design patterns are dynamite
  25. 25. design pattern is a general reusable solution to a commonly occurring problem within a given context [in software design]
  26. 26. Powerful tool ! Never use when not 100% sure that needed ! Disastrous in inexperienced hands
  27. 27. Experts trying to save your project after too many design patterns in wrong places
  28. 28. UX and SA go hand in hand
  29. 29. Requirements wireframes and interaction design software architecture code
  30. 30. Performance is not an afterthought
  31. 31. HOWTO not fail with performance Define performance Measure performance ! ! • Customer requirement • Performance goal is a number • Performance has a cost • Benchmark regularly • Start measuring before app is built • React regressions immediately
  32. 32. Architecture for a Library
  33. 33. "Don't ever code anything which has public API. You will be sorry" - Artur Signell
  34. 34. Someone else's application Your library depends on Public Architecture! +! API depends on Internal Architecture! +! API
  35. 35. 2001
  36. 36. Web-browser Http-req. XHTML Millstone Web Adapter State change Data source UI Component Event 2003 XML Change Application logic
  37. 37. 2013
  38. 38. When you do not know how it should work, please do not hide it behind an abstraction
  39. 39. Architect who is not a developer is not an architect
  40. 40. ? joonas@vaadin.com vaadin.com/joonas @joonaslehtinen

×