notes on architecture
DESCRIPTION
TRANSCRIPT
Dr. Joonas Lehtinen Founder & CEO / Vaadin
Notes on Architecture
Structure [only] when needed
Nightmare
Dream
Last name
varchar: !LAST_NAME
Over-designed architecture
Increases risks by making implementation complex
Tries to achieve fault-tolerance or scalability never needed
Prepares for expansion and changes that will never happen
Software architecture danger #1
If you are not 100% sure that a
requirement is solid, choose a simpler
structure even when the requirement night
not be fulfilled
All requirements having an impact on architecture must have clear metrics and goals
Learn to estimate and communicate cost impacts to negotiate requirements
Overgeneralization
Custo
miz
ation b
y P
rogra
mm
ing
Custo
miz
ation b
y C
onfiguring
Report(XSL)
ReportExample
Millstone Cards 2.0
CustomCard UI
External System
Custom Data-
Source
Settings(XML)
Theme(HTML, CSS, ...)
SQL DBWeb
Browser
External Reporting System
SettingsExample
ThemeExample
Card UIExample
System Integration Example
Data-Source
Example
Millstone Cards 2.0 Structure
Over-generalization
Tries to overcome unknown requirements
Moves the unknown to layers where it should not be (UI or user)
Claims that your software can do thinks that you do not know
Software architecture danger #2
Decoupling tries to reduce complexity by adding complexity
You are now prepared to change a meatball
do I really
need to change it?
De-coupling
Will make your system slower to build, but could make it easier to maintain
Can make your system harder to understand (more modules and interfaces)
Can make your system easier to understand (modules decoupled)
Two edged sword of software architecture
Decouple only things that should be built
separately. !
Decouple for readability, not for potential change.
For the love of Refactoring
Refactoring is very cheap. Rewriting (working parts) is cheaper than you think. Cleaning up the mess late never happens. Keep your room tidy!
#1 Choose a statically typed language or loose refactoring tooling support
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
Art of naming
Naming
One of the hardest tasks
Critical for clarity
Takes a lot of time when done properly
Should be debated in code review
Sign of a good architecture
Good name
Short
Documents the described thing
Unique (for project and domain)
Intuitive
Follows project style
Design patterns are dynamite
design pattern is a general reusable solution to a commonly occurring problem within a given context [in software design]
Powerful tool !
Never use when not 100% sure that needed !
Disastrous in inexperienced hands
Experts trying to save your project after too many design patterns in wrong places
UX and SA go hand in hand
wireframes and interaction design
code
software architecture
Requirements
Performance is not an afterthought
HOWTO not fail with performance
Define performance !• Customer
requirement • Performance goal
is a number • Performance has
a cost
Measure performance !• Benchmark
regularly • Start measuring
before app is built • React regressions
immediately
Architecture for a Library
"Don't ever code anything which has public API. You will be sorry"
- Artur Signell
Internal Architecture!+!
API
Public Architecture!+!
API
Your
libr
ary
Someone else's application
depends on
depends on
2001
UIComponent
MillstoneWeb Adapter
Applicationlogic
Web-browser
XHTMLHttp-req.
XMLState change
ChangeEvent
Data source
2003
2013
When you do not know how it should work, please do not hide it behind an abstraction
Architect who is not a developer is not an architect
