Skip to content
Fix Bugs on Legacy Code

Legacy Coderetreat: Part 4 – Fix bugs on Legacy Code

Fix bugs on legacy code

Blog post series

This blog post is part of a series about legacy coderetreat and legacy code techniques you can apply during your work. Please click to see more sessions about legacy code.

Purpose

When we need to fix bugs on legacy code, we first need to understand if the described behaviour is in fact a bug or not. For that we can write some characterization tests in order to understand what the system really does. The simplest form of characterization test is a system test. A couple of ideas to start writing the characterization tests are to use the generic approach Part 2 – From Nothing to System Tests and Part 3 – Golden Master. We can generate system tests considering that the System Under Test (SUT) is a black box. You can find more details about how to do that in the blog posts and code casts about the above techniques. But in order to fix bugs on legacy code we need to dive more into the code base. We need to write tests on a smaller scope and we often need to refactor in order to make room for the code changes. Let’s see a technique of fixing a bug in legacy code.

Fix bugs on legacy code
Fix bugs on legacy code

A community event: Bring your own code

Bring your own code

Last month I started a new community event idea. It is called “Bring your own code”, and I “stole” it from what Antoine Vernois is doing in the Toulouse Software Craftsmanship Community. You can find here the event page. Tomorrow we will have the second edition that you can find here. Let’s go a bit into the mechanics of this event type.

Why

  • You have a project and you want a second opinion.
  • Your code needs improvements and you do not know where to start from.
  • You just like to show some awesome code and give it as an example.
Bring Your Own Code
Bring Your Own Code
Architectural Kata Budapest

Architectural Kata – Budapest

Architectural Kata Budapest

Following the invitation of Zsolt Bodo I facilitated an Architectural Kata in the Budapest Agile community. The purpose of the session was to let the attendees speak about architecture and I was merely a facilitator. My other role was the customer, clarifying the requirements whenever the audience requested.

The concept remains the same as for the first Architectural Kata I facilitated: you cannot be a good architect if you do not have the experience. An architect creates 10-15 architectures during the whole career, so we need to practice to become better architects. This session is exactly a repetitive exercise of creating architectures for given, unclear, requirements.

Architectural Kata Budapest
Architectural Kata Budapest

Code and beer – First experience

Code and Beer

I wanted for a long time to organize a gathering of programmers where anyone can come and go whenever they please. One year ago I read about the “Code & Coffee” and the “Code & Beer” events that happen in the world, but I was more familiar with the ones in USA and UK. Because I do not drink coffee, and because it’s reaaaally hard to meet-up with someone living in Bucharest at 7:00 AM, I decided to try the “Code and Beer” experience.

The first thing I did was to ask Sandro Mancuso, the amazing force behind the London Software Craftsmanship Community, to help me a bit to organize the first Code & Beer. He gave me some good advices: give a quick intro about the group and future events,  start with quick introductions during which people say what they want to do (pet project, kata, just have a drink and decide later), ask if any one wants to give lightning talks, encourage people to pair, enjoy the evening.