Yet Another Software Engineering Blog

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.