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!)
- 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.
- 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”
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.
- Overall strategy
- 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
- C. Lilienthal: Langlebige Software-Architekturen: Technische Schulden analysieren, begrenzen und abbauen
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.
- 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
Talk 4: What is (not) Software Crafters?
Daniel Carral (@dcarral) talks about the term Craftmanship and the community behind this movement.
- The Craftmanship Manifesto
- Open Space Technology
- Apprenticeship Pattern
- 17.11.2018 Global Day of Coderetreat
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.
- 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