Mark Richards
- Intro
- Architecture and structural decay
- Metrics and structural decay
- Architecture analysis tools (x ray, code city, source monitor)
An architect is expected to analyze the current technology environment and recommend solutions for improvement.
Applications often start out simple, small, understated.
Over time they grow and their initial structure is not sufficient to grow with it.
What does it mean to assess and architecture? Do we have the correct architecture for the current problem?
Once structures start to fall down then the system will not be able to be extended further.
Overall structure of the application with overall design principles.
What architectural patterns are we using? There are 8 core common patterns.
Scalability, Availability, Reliability
The architect lays out the architectural components
- Inventory Manager
- Order Placement
- Customer Notification
- Reference Manager
- Order Fulfillment
- Customer Tracking
Designers and programmers fill in the details within those components.
- Component or service size -
- Temporal coupling - every time component x has an issue or a change then this other thing has to change.
- Static coupling - afferent, efferent coupling (packages, classes)
- Shared libraries - the more shared libraries means there is more coupling
- Aggregation requests -
- Inter service communication -
- Plugin dependencies (microkernel) - there should be no dependencies between different plugins
- Intellij forbids coupling between plugins, Eclipse allows it and it is now unusable
- Cross-domain coupling
- High degree of complexity
- Database coupling
- Volatility hotspots
Symptoms (not leading indicators)
- complex and error-prone deployments
- hard for new people to learn the code base
- slowdown in development
We will be looking at source code to help us decide if we have a need for architectural change.
cc = n - e + 2
Other:
- number of classes per package
- number of lines of source code
- percent comments (8%-20%, higher?) - comment why not how
- max complexity mc = 1+paths thru method, 2-8 is reasonable measures testability
- average depth (range 1.0-2.8) average depth of code within a method.
- average complexity
- DIT (depth of inheritance) - about modularity
- WMC - weighted methods/class, sum of CC
- CE - efferent coupling count
- CA - afferent coupling count
We want to avoid classes with few methods but a lot of code.
Show you component (package, city block). The buildings have height (# of methods), and width (attributes).
- classes #
- line #
- statements
- %comments
- max complexity
- methods
- branches
What about SonarQube?