Software Engineering for Smart Data Analytics & Smart Data Analytics for Software Engineering

User Tools

Site Tools

Refactoring and Patterns, Refactoring to Patterns, Code Quality

Slides: Code Quality
Experts: Paul Heckmann, Andri Bremm, Malkhaz Gaprindashvili
Contact: Daniel Speicher

Three times Five points to remember

  1. ?
  2. ?
  3. ?
  4. ?
  5. ?
  1. ?
  2. ?
  3. ?
  4. ?
  5. ?
  1. ?
  2. ?
  3. ?
  4. ?
  5. ?

Question and Answers

  • Q: What is the definition of the metrics Instability and Abstractness?
  • Q: Why should we avoid dependency cycles?
  • Q: Does controlling metrics lead to good code quality?
  • Q: What is the meaning of linear independence of execution paths in the context of the definition of McCabes Cyclomatic Complexity?
  • Q: Where do the thresholds for the risk levels for the Cyclomatic Complexity relate to? How big was the measured code?


  • Agile Code Quality: Run all tests, Eliminate duplication, Express all ideas, Minimize entities
  • In earlier labs we called this topic refactoring, but we realized that the students didn't refactor that often. We think the reason was that though everybody knew refactoring is a good thing one should do, we had no clear goal that we wanted to achieve by doing our refactorings. So here are the goals: Eliminate duplication, express all ideas, minimize entities.

Suggested outline of the talk

The talk could be based on the refactoring exercise, we used in earlier labs.

  • (“Minimize Entities”, “Avoid Duplication”)
    • Why is unnecessary code waste? (see [PP03])
  • “Avoid Duplication”
    • Present a tool that detects duplication (e.g. Simian).
    • Explain the basic idea of behavior preserving restructurings for design improvements (=refactorings) showing some “extract” refactorings.
    • There is duplication in the ThreeKeyCupApp.
  • “Express all ideas” (⇒ Naming, High Cohesion)
    • Argue that naming is essential for program understanding.
    • Present automated “rename” refactorings.
      • All essential concepts should be present in the code so that we don't need further documentation.
      • No comments inside method bodies, instead extract methods with meaningful names.
    • Show classes with low cohesion (e.g. using the metric LCOM2 calculated by the Metrics Plugin)
    • There are uncohesive classes in the ThreeKeyCupApp.
  • “Express all ideas”, “Minimize Entities” (⇒ Low Coupling)
    • Argue that high coupling and especially dependency cycles are a burden to software evolution.
      • A layered architecture avoids dependency cycles. Gives an idea about intended amount of reuse (~abstraction).
    • Show a dependency cycle. (e.g. using the Metrics Plugin or the Code Analysis Plugin)
    • Demonstrate how this can be solved using the Observer Pattern.
    • Remind us that there are more patterns.
    • There is a dependency cycle in the ThreeKeyCupApp.
  • (“Run all tests”), Keep the number of required tests low
    • Show classes with high Cyclomatic Complexity and explain why high Cyclomatic Complexity requires many test cases.
    • Demonstrate how the Observer Pattern in is a special case of applying the Dependency Inversion Principle, which is also useful to make classes testable.


  • [PP03] Poppendieck & Poppendieck: Lean Development
  • [Fo99] Martin Fowler: Refactoring: Improving the Design of Existing Code
  • [GHJV94] Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides: Design Patterns - Elements of Reusable Object-Oriented Software
  • More resources on demand
teaching/labs/xp/2009a/topic_code_quality.txt · Last modified: 2018/05/09 01:59 (external edit)

SEWiki, © 2024