Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

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

347 views

Published on

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.

Published in: Technology
  • Be the first to comment

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

  1. 1. 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
  2. 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
  3. 3. Copyright © 2014 Oracle and/or its affiliates. All rights reserved. | About me 4
  4. 4. Copyright © 2014 Oracle and/or its affiliates. All rights reserved. | About me 5
  5. 5. Copyright © 2014 Oracle and/or its affiliates. All rights reserved. | Giveaway • Lean Architecture by Coplien & Bjornvig 6
  6. 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
  7. 7. Copyright © 2014 Oracle and/or its affiliates. All rights reserved. | “Architectural Decay” The Problem 8
  8. 8. 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
  9. 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 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
  10. 10. 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
  11. 11. 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
  12. 12. 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
  13. 13. Copyright © 2014 Oracle and/or its affiliates. All rights reserved. | “Architectural Agility” The SoluAon 14
  14. 14. 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
  15. 15. 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
  16. 16. 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
  17. 17. Defining your RelaEonships Copyright © 2014 Oracle and/or its affiliates. All rights reserved. | 18
  18. 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
  19. 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
  20. 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
  21. 21. 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!
  22. 22. Copyright © 2014 Oracle and/or its affiliates. All rights reserved. | Packages Compare these approaches: 23 • Package-­‐by-­‐layer • Package-­‐by-­‐feature
  23. 23. 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
  24. 24. Tracking and Enforcing in AcEon Copyright © 2014 Oracle and/or its affiliates. All rights reserved. | 25
  25. 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
  26. 26. StaEc Code Analysis and the “Big Picture” javac! Copyright © 2014 Oracle and/or its affiliates. All rights reserved. | 27
  27. 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
  28. 28. 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
  29. 29. 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
  30. 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
  31. 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
  32. 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
  33. 33. 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>
  34. 34. 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
  35. 35. Copyright © 2014 Oracle and/or its affiliates. All rights reserved. | 36

×