JDD2014: Enforcing architecture patterns with static code analysis - Pablo Barros

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


•  The opinions and views expressed in this talk are my own, and do not necessarily reflect the opinions or views of my employer.

3


About me

4


About me

5


Giveaway

•  Lean Architecture by Coplien & Bjornvig

6


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


“Architectural Decay” The Problem

8


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


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


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


Architecture Work as Systems Grow

12

Archite

cture Work

Time/Growth

Major Features

Rewrite Sefng up foundaEon


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


“Architectural Agility” The SoluAon

14


Defining “Architectural Agility”

15

• “Just Enough” Informed AnEcipaEon – Dependency Analysis – Real OpEon Analysis – Technical Debt Management


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


Technical Debt Management

• Refactoring of relaEonships between components is expensive •  Lack of “Architecture Agility” compromises “Enhancement Agility”

17


Defining your RelaEonships

18


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


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


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


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!


Packages Compare these approaches:

23

• Package-‐by-‐layer • Package-‐by-‐feature


AnE-‐PaBerns Not just your average “code smell”

• Big ball of Mud • Circular Dependency •  Jumble • Object cesspool • Object orgy •  SequenEal coupling

24


Tracking and Enforcing in AcEon

25


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


StaEc Code Analysis and the “Big Picture”

javac!

27


Common Usage of SCA

28

•  Finding bugs and code smells •  Security vulnerabiliEes (certain types) • Unit test coverage


Tools

• General – NaEve IDE Support •  Eclipse, IntelliJ, Jdeveloper

– FindBugs – Coverity

• Dependency-‐analyzer – Dependency Finder – JDepend

29

• Architecture-‐focus – Sonargraph – Lafx Architect – Structure101


Demo Spring Petclinic Sample ApplicaAon

• Define Layers and Slices • Plugging into the IDE

•  Image Credit: hBps://speakerdeck.com /michaelisvy/spring-‐petclinic-‐sample-‐applicaEon

30


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


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


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


Q&A Thank you!

34

MulAtenant Search Tomorrow – 17:00 <Sputnik Track>

Also checkout session:


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

Technology

JDD2014: Enforcing architecture patterns with static code analysis - Pablo Barros