More Related Content Similar to JDD2014: Enforcing architecture patterns with static code analysis - Pablo Barros (20) JDD2014: Enforcing architecture patterns with static code analysis - Pablo Barros2. Enforcing
Architecture
PaBerns
with
StaEc
Code
Analysis
JDD
2014,
Krakow
-‐
PL
Copyright
©
2014
Oracle
and/or
its
affiliates.
All
rights
reserved.
|
Pablo
Barros
ApplicaEons
Architect
October
13,
2014
3. Copyright
©
2014
Oracle
and/or
its
affiliates.
All
rights
reserved.
|
• The
opinions
and
views
expressed
in
this
talk
are
my
own,
and
do
not
necessarily
reflect
the
opinions
or
views
of
my
employer.
3
4. Copyright
©
2014
Oracle
and/or
its
affiliates.
All
rights
reserved.
|
About
me
4
5. Copyright
©
2014
Oracle
and/or
its
affiliates.
All
rights
reserved.
|
About
me
5
6. Copyright
©
2014
Oracle
and/or
its
affiliates.
All
rights
reserved.
|
Giveaway
• Lean
Architecture
by
Coplien
&
Bjornvig
6
7. Copyright
©
2014
Oracle
and/or
its
affiliates.
All
rights
reserved.
|
Agenda
The
Problem:
“Architectural
Decay”
The
SoluEon:
“Architectural
Agility”
Defining
your
RelaEonships
Tracking
and
Enforcing
in
AcEon
Q&A
7
1
2
3
4
5
8. Copyright
©
2014
Oracle
and/or
its
affiliates.
All
rights
reserved.
|
“Architectural
Decay”
The
Problem
8
9. What
is
So_ware
Architecture?
Copyright
©
2014
Oracle
and/or
its
affiliates.
All
rights
reserved.
|
• IEEE
1471-‐2000
defines:
“So_ware
architecture
is
the
fundamental
organizaEon
of
a
system,
embodied
in
its
components,
their
relaEonships
to
each
other
and
the
environment,
and
the
principles
governing
its
design
and
evoluEon.”
9
10. What
is
So_ware
Architecture?
Copyright
©
2014
Oracle
and/or
its
affiliates.
All
rights
reserved.
|
• IEEE
1471-‐2000
defines:
“So_ware
architecture
is
the
fundamental
organizaAon
of
a
system,
embodied
in
its
components,
their
relaAonships
to
each
other
and
the
environment,
and
the
principles
governing
its
design
and
evoluAon.”
10
11. Architecture
Degenerates
Over
Time
“As
a
system
evolves,
its
complexity
increases
unless
work
is
done
to
maintain
or
reduce
it.”
Copyright
©
2014
Oracle
and/or
its
affiliates.
All
rights
reserved.
|
-‐-‐Lehman’s
Laws
of
So.ware
Evolu4on
(1980)
11
12. Architecture
Work
as
Systems
Grow
Major
Features
Copyright
©
2014
Oracle
and/or
its
affiliates.
All
rights
reserved.
|
12
Architecture
Work
Time/Growth
Sefng
up
foundaEon
Rewrite
13. Reasons
for
“Architecture
Decay”
Copyright
©
2014
Oracle
and/or
its
affiliates.
All
rights
reserved.
|
• Increased
system
complexity
• Architecture
is
not
documented
• Developers
don’t
know
or
don’t
understand
• “Shortcuts”
caused
by
Eght
deadlines
• Division
of
work
on
different
disperse
teams
13
14. Copyright
©
2014
Oracle
and/or
its
affiliates.
All
rights
reserved.
|
“Architectural
Agility”
The
SoluAon
14
15. Defining
“Architectural
Agility”
Copyright
©
2014
Oracle
and/or
its
affiliates.
All
rights
reserved.
|
15
• “Just
Enough”
Informed
AnEcipaEon
– Dependency
Analysis
– Real
OpEon
Analysis
– Technical
Debt
Management
16. Copyright
©
2014
Oracle
and/or
its
affiliates.
All
rights
reserved.
|
Dependency
Analysis
• Cost
of
Change
PropagaEon
• Visibility
of
likely
affected
areas
16
Spring
3.0
Module
Dependencies
hBp://www.ogrigas.eu/spring/2009/12/diagram-‐of-‐spring-‐3-‐0-‐module-‐dependencies
17. Copyright
©
2014
Oracle
and/or
its
affiliates.
All
rights
reserved.
|
Technical
Debt
Management
• Refactoring
of
relaEonships
between
components
is
expensive
• Lack
of
“Architecture
Agility”
compromises
“Enhancement
Agility”
17
19. Copyright
©
2014
Oracle
and/or
its
affiliates.
All
rights
reserved.
|
RelaEonships
• Layers
– Horizontal
Slices
of
the
System
• Examples:
Controller,
Service,
DAO,
Model,
View.
– How
different
layers
can
interact?
– And
cannot
interact?
• Modules
– VerEcal
Slices
of
the
System
• Examples:
Catalog,
Inventory,
Ordering,
ReporEng.
– How
different
modules
can
interact?
And
cannot
interact?
19
20. Copyright
©
2014
Oracle
and/or
its
affiliates.
All
rights
reserved.
|
Layers
• Organized
in
Package-‐based
hierarchy
• Layers
of
a
same
“Module”
are
built
together
in
a
single
JAR
• How
do
we
prevent
introducing
unwanted
dependencies
between
layers?
20
21. Copyright
©
2014
Oracle
and/or
its
affiliates.
All
rights
reserved.
|
Modules
• Few
opEons:
– OSGi
Bundles
– Jars
– Packages
• How
do
we
prevent
introducing
unwanted
dependencies
between
modules?
• How
big/small
should
a
module
be?
21
Spring
3.0
Module
Dependencies
hBp://www.ogrigas.eu/spring/2009/12/diagram-‐of-‐spring-‐3-‐0-‐module-‐dependencies
22. Copyright
©
2014
Oracle
and/or
its
affiliates.
All
rights
reserved.
|
Packages
You
want
to
be
able
to
slice
and
dice
them
22
• Adopt
a
package
convenEon
and
sEck
with
it!
• Package-‐by-‐feature
vs.
Package-‐by-‐Layer
• For
example:
com.company.product.module.layer!
com.company.product.layer.module!
23. Copyright
©
2014
Oracle
and/or
its
affiliates.
All
rights
reserved.
|
Packages
Compare
these
approaches:
23
• Package-‐by-‐layer
• Package-‐by-‐feature
24. Copyright
©
2014
Oracle
and/or
its
affiliates.
All
rights
reserved.
|
AnE-‐PaBerns
Not
just
your
average
“code
smell”
• Big
ball
of
Mud
• Circular
Dependency
• Jumble
• Object
cesspool
• Object
orgy
• SequenEal
coupling
24
26. Copyright
©
2014
Oracle
and/or
its
affiliates.
All
rights
reserved.
|
StaEc
Code
Analysis
(SCA)
• Cheaper
and
more
efficient
to
find
certain
types
of
bugs
than
code
reviews
– Not
meant
to
replace
them
• Reduce
need
for
knowledge
of
large
frameworks
• Allow
for
excepEons
(as
opposed
to
a
compiler)
• Good
at
Enforcing
Standards
and
Best
PracEces
• Can
be
Automated
• Early
in
the
Development
Process
26
27. StaEc
Code
Analysis
and
the
“Big
Picture”
javac!
Copyright
©
2014
Oracle
and/or
its
affiliates.
All
rights
reserved.
|
27
28. Copyright
©
2014
Oracle
and/or
its
affiliates.
All
rights
reserved.
|
Common
Usage
of
SCA
28
• Finding
bugs
and
code
smells
• Security
vulnerabiliEes
(certain
types)
• Unit
test
coverage
29. Copyright
©
2014
Oracle
and/or
its
affiliates.
All
rights
reserved.
|
Tools
• General
– NaEve
IDE
Support
• Eclipse,
IntelliJ,
Jdeveloper
– FindBugs
– Coverity
• Dependency-‐analyzer
– Dependency
Finder
– JDepend
29
• Architecture-‐focus
– Sonargraph
– Lafx
Architect
– Structure101
30. Copyright
©
2014
Oracle
and/or
its
affiliates.
All
rights
reserved.
|
Demo
Spring
Petclinic
Sample
ApplicaAon
• Define
Layers
and
Slices
• Plugging
into
the
IDE
• Image
Credit:
hBps://speakerdeck.com
/michaelisvy/spring-‐petclinic-‐sample-‐applicaEon
30
31. Copyright
©
2014
Oracle
and/or
its
affiliates.
All
rights
reserved.
|
Making
it
Work
• Integrate
into
Build
System
• Define
Owners
• Maintain
and
Grow
set
of
Rules
– New
Rules
come
out
of
Code
Reviews
findings
and
discussions
– Rules
are
categorized
in
different
Severity
Levels
• Define
AcEons
required
depending
on
different
Severity
Levels
• Follow
through
31
32. Copyright
©
2014
Oracle
and/or
its
affiliates.
All
rights
reserved.
|
Measuring
Quality
• Not
every
warning
needs
to
be
“Fixed”
• Keep
a
pulse
on
overall
number
of
warnings
• Focus
on
High
Priority
warnings
• Monitor
– Overall
number
of
warnings
– Code
fragmentaEon
– Code
coverage
(Unit
tests)
32
33. Copyright
©
2014
Oracle
and/or
its
affiliates.
All
rights
reserved.
|
Final
Thoughts
1. Take
the
first
step,
download
and
evaluate
different
tools
2. Look
at
your
current
system
3. Define
basic
structures
to
“stop
the
bleeding”
4. Integrate
into
your
build
system
5. Incrementally
tackle
and
solve
problems
as
you
work
on
different
areas
of
your
applicaEon
Be
smart
around
your
package
structure!
33
34. Also
checkout
session:
Copyright
©
2014
Oracle
and/or
its
affiliates.
All
rights
reserved.
|
Q&A
Thank
you!
34
MulAtenant
Search
Tomorrow
–
17:00
<Sputnik
Track>
35. References
and
Further
Reading
• hBp://www.crosstalkonline.org/storage/issue-‐archives/
2010/201011/201011-‐Brown.pdf
• hBp://www.ksi.edu/seke/Proceedings/seke11/166_Lei_Zhang.pdf
• hBp://www.infoq.com/arEcles/architecture-‐and-‐agility-‐good-‐friends
• hBp://www.sonarqube.org/evaluate-‐your-‐technical-‐debt-‐with-‐sonar/
Copyright
©
2014
Oracle
and/or
its
affiliates.
All
rights
reserved.
|
35