jdd2014: enforcing architecture patterns with static code analysis - pablo barros
DESCRIPTION
As systems grow, many of the overarching architectural principles become less obvious to developers. It is important to preserve these principles intact and visible to all folks that interact with the code base. In this session, we will review a number of static code analysis tools, starting with localized analysis of code snippets; create strategies for catching violations of application-wide design patterns; and review tools for automating and hooking the static code analysis to source control and build systems.TRANSCRIPT
Copyright © 2014 Oracle and/or its affiliates. All rights reserved. |
Enforcing Architecture PaBerns with StaEc Code Analysis JDD 2014, Krakow -‐ PL
Pablo Barros ApplicaEons Architect October 13, 2014
2
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
Copyright © 2014 Oracle and/or its affiliates. All rights reserved. |
About me
4
Copyright © 2014 Oracle and/or its affiliates. All rights reserved. |
About me
5
Copyright © 2014 Oracle and/or its affiliates. All rights reserved. |
Giveaway
• Lean Architecture by Coplien & Bjornvig
6
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
Copyright © 2014 Oracle and/or its affiliates. All rights reserved. |
“Architectural Decay” The Problem
8
Copyright © 2014 Oracle and/or its affiliates. All rights reserved. |
What is So_ware Architecture?
• 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
Copyright © 2014 Oracle and/or its affiliates. All rights reserved. |
What is So_ware Architecture?
• 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
Copyright © 2014 Oracle and/or its affiliates. All rights reserved. |
Architecture Degenerates Over Time
“As a system evolves, its complexity increases unless work is done to maintain or reduce it.”
-‐-‐Lehman’s Laws of So.ware Evolu4on (1980)
11
Copyright © 2014 Oracle and/or its affiliates. All rights reserved. |
Architecture Work as Systems Grow
12
Archite
cture Work
Time/Growth
Major Features
Rewrite Sefng up foundaEon
Copyright © 2014 Oracle and/or its affiliates. All rights reserved. |
Reasons for “Architecture Decay”
• 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
Copyright © 2014 Oracle and/or its affiliates. All rights reserved. |
“Architectural Agility” The SoluAon
14
Copyright © 2014 Oracle and/or its affiliates. All rights reserved. |
Defining “Architectural Agility”
15
• “Just Enough” Informed AnEcipaEon – Dependency Analysis – Real OpEon Analysis – Technical Debt Management
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
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
Copyright © 2014 Oracle and/or its affiliates. All rights reserved. |
Defining your RelaEonships
18
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
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
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
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!
Copyright © 2014 Oracle and/or its affiliates. All rights reserved. |
Packages Compare these approaches:
23
• Package-‐by-‐layer • Package-‐by-‐feature
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
Copyright © 2014 Oracle and/or its affiliates. All rights reserved. |
Tracking and Enforcing in AcEon
25
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
Copyright © 2014 Oracle and/or its affiliates. All rights reserved. |
StaEc Code Analysis and the “Big Picture”
javac!
27
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
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
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
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
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
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
Copyright © 2014 Oracle and/or its affiliates. All rights reserved. |
Q&A Thank you!
34
MulAtenant Search Tomorrow – 17:00 <Sputnik Track>
Also checkout session:
Copyright © 2014 Oracle and/or its affiliates. All rights reserved. |
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/
35
Copyright © 2014 Oracle and/or its affiliates. All rights reserved. | 36