The Clean Code Days in Munich is a developer conference about the “Clean Code Movement”. The main topics are code quality aspects, team dynamic and design principles. This post gives a small summary including the key aspects of the talks I participated in.

Keynote: Test Intelligence?

The first day started with the keynote by Dr. Elmar Jürgens (@ElmarJuergens) about Test Intelligence. This talk explains how existing data can be used to answer the questions what should be tested, which change were omitted during tests and which test execution order is the best to fail fast (this can minimize the feedback loop!)

Key Aspects

  • Changes are a good predictor to spot sources for failures
  • A simple tree map is a helpful tool to get insights about your source code: each rectangle represents a component (e.g. a class, module or file). The size of the rectangle relates to the size of the component (e.g. lines of code, complexity etc.). Additionally, each component can be colored depending if it was added, modified or not touched. This could also be combined with test coverage data
  • One should also collect coverage data of the production code (e.g. code which is never executed in production is not very useful)
  • Defect prediction is not better than random guessing
  • Test-Gap-Analysis is a useful concept which combines the information what was changed and what is covered by tests
  • Test-Impact-Analysis can be used to select which test cases should be used in the CI-Pipeline
  • Ticket-Coverage is useful to verify if the important features will be covered by tests

Talk 1: Clean Code is a Team Sport!

Michael Kaufmann (@mike_kaufmann) explained the development of a developer in his talk about “Clean Code is a Team Sport!”. He moved the focus to technical debts since he defines clean code as “the absence of technical debts”. Instead of strictly forbid technical debts he claims to manage them and actively decide which shortcuts to take and when to clean up with technical debts.

Key Aspects

  • Clean code is about communication!
  • The team must have the ownership of the code – and not the individual developer
  • Technical debts slows down development
  • It is crucial to define what technical debts mean for you in order to measure and manage them accordingly
  • Technical debts is not only about static code analysis. Take code coverage, documentation, software design and metrics into account, too!
  • Establish a “Feedback culture”

References

 

Talk 2: Software Quality in in einem Legacy Project

Jeanette Wernicke shares her experience with software quality especially in “long-lasting” projects with developers in different generations. She describes a legacy project as a project which is a long time in production already, has nearly no documentation, lots of dependencies as well as technical debts and it takes a long period of vocational adjustment.

Key Aspects

  • Overall strategy
    • Apply the “Scout Law”
    • Make a Hotspot Analysis (e.g. with SoftVis3D or Seerene)
    • Make a structural adjustment of your software architecture
  • It is important to make the Software Quality transparent
  • Display your dependencies graphically (e.g with Sonargraph)
  • Build a model of your architecture which defines allowed dependencies (then check if these rules will be met)
  • Give your components names which defines what they do and what they are allowed to do

References

Talk 3: Anwendung vom Single Responsibility Prinzip

The definition of the Single Responsibility Principle is very ambiguous. Robert Bräutigam (@robertbrautigam) explains his understanding of this principle from a “object oriented” point of view.

Key Aspects

  • The SRP is about cohesion and coupling: Try to maximize cohesion and minimize coupling
  • Take care about dependencies, especially semantical dependencies are evil
  • Using getters often leads to semantical coupling
  • Introduce abstractions instead relying on concrete classes

References

Talk 4: What is (not) Software Crafters?

Daniel Carral (@dcarral) talks about the term Craftmanship and the community behind this movement.

Key Aspects

References

Coding Dojo: “Tests gegen Bugs”

The first conference day ends with a Coding Dojo Session by Roland Galla from @nevercodealone. Roland showed us the simple steps to set up codeception to create a set of regression tests.

Key Aspects

  • A CI-Pipeline should not last longer than 5 minutes
  • Use the “Copy Selector” feature of chrome dev tools to get element selectors more easily
  • Codeception has a seperate Assert-Module for assertions in acceptance tests

References