Tag Archives: Coderetreat

The Coderetreat Book

The Coderetreat Book

About

A couple of weeks ago I published the Coderetreat book together with Alex Bolboacă. The book is about how to facilitate and host a coderetreat event.

front-cover

Contents

It contains plenty of ideas and advice from both of us, based on our experiences of organizing, hosting and facilitating many coderetreats the least 7 years. The book contains specific advice on how to host and facilitate. Also a list of sessions is available in the book. Each session is documented in detail.

This is the first edition of the book, and we launched it now especially for the Global Day of Coderetreat (GDCR) 2016. We hope this book will help hosts and facilitators have wonderful events around the globe during GDCR.

Feedback wanted please

We plan to enhance the book with more chapters and more sessions. For now just enjoy the book and we hope we will receive plenty of feedback from you. We want the book to help you if you are organizing, hosting or facilitating a Coderetreat. Please tell us if it helped you, or how we could improve it for you. Thank you!

Programming by Wishful Thinking

Coderetreat: Programming by Wishful Thinking

Blog post series

This blog post is part of a series about coderetreat sessions.

Purpose

This session introduces the concept of top-down approach of Test Driven Development for a new feature.
By following the steps you will be able to understand how to add thin top-down features that you can show very fast to your customers. Many of the features will work, even though you will not have a fully functional system, just because you have used stubs or fakes for the parts of the system that are not yet implemented.

Programming by Wishful Thinking

Read More →

Legacy Coderetreat: Part 16 – Refactor Conditionals by Decomposing Conditional

Refactor conditionals by Decompose Conditional

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.

IF-THEN-ELSE-END_flowchart

Purpose

We often see code with conditionals that are hard to understand. The purpose of this technique is to make the code look readable by extracting a function with the condition. It will be easier to test the code if the condition is extracted and injected as a dependency.

This technique is useful when having good variable names is not enough to explain the condition. We can have some of the following reasons for wanting to extract a function with the condition:

  • The condition is duplicated in several parts of the class
  • The condition is duplicated along different classes
  • Test the condition in isolation, because of its complex nature
  • Test the code without understanding how the conditions work (inject conditions as stubs)

 

Read More →

Legacy Coderetreat: Part 15 – Refactor Conditionals by Explaining Variable

Refactor conditionals: Explain Variable

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. Refactor Conditionals - Explain Variable

Purpose

When you try to read a code base that has many conditionals, often the problem is that the condition itself is very hard to understand. This technique improves the conditionals by making them clear and very easy to read. Read More →

Legacy Coderetreat: Episode 13 – Document Possible Bugs with Tests – Code Cast

Document Possible Bugs with Tests – code cast

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.

Code Cast

This is a code cast in Java.

In the previous episodes we reach the moment when we extracted one simple class. We used the The Rule of Three and pure functions. This newly extracted class is covered with characterization tests. Then we wrote some unit tests in the following episode. But some of the behaviours seemed strange, and we thought they might be bugs.

Because we are never sure when working on existing code if some behaviour is a bug or a feature, we want to document all the suspicious cases. In order to do that, I am presentin three methods: use an annotation, prefix the test, use a diffent class.

Bug or feature? Check out the code cast to see all of them in action.

Read here more about this concept in my blog post.

Legacy Coderetreat: Episode 12 – Unit Testing on Legacy Code – Code Cast

Unit Testing on Legacy Code – code cast

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.

Code Cast

This is a code cast in Java.

In the previous episodes we reach the moment when we extracted one simple class. We used the The Rule of Three and pure functions. This newly extracted class is covered with characterization tests. But that is not enough, we want to continue adding other types of tests to understand the system better.

This is why during this episode you will see how to add unit tests to code extracted from a legacy code class. These tests have a small granularity level than the characterization tests we already have. This is the moment to dive more into details.

See this video to understand how you can document the current state of the system, by unit testing on legacy code.

Read here more about this concept in my blog post.

Legacy Coderetreat: Episode 11 – Extract Class – Code Cast

Extract Class – code cast

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.

Code Cast

This is a code cast in Java.

In the previous episodes we restructured some parts of the code base. We also extracted pure functions and applied The Rule of Three when restructuring the code.

Because we have extracted some pure functions, now we need to think if those pure functions belong to new classes. So we structure the functions in a way that they belong together from the point of view of their responsibilities. After structuring the functions we extract the class.

Learn from this video how to extract a class in legacy code in such a way that you do not introduce side-effects to the existing behaviour.

Read here more about this concept in my blog post.

Legacy Coderetreat: Episode 10 – Refactoring the Rule of Three – Code Cast

Refactoring the Rule of Three – code cast

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.

Code Cast

This is a code cast in Java.

When refactoring legacy code we need to make sure the structures we extract have a correct meaning. This is why The Rule of Three is very useful: extract to a new structure only when you find an identical duplication three times. Usually we do not have identical duplication, so in that case we need to make the duplication clear, check that it exists three times and only after that perform the extraction.

This code cast will show you also when it is not a good idea to extract a new variable, even if you see it duplicated many times. This is a mechanical kind of refactoring, but reasoning is very important even when we want to get fast by getting mechanical refactorings into our tool bag.

Read here more about this concept in my blog post.

Legacy Coderetreat: Episode 9 – Extract Pure Functions – Code Cast

Extract Pure Functions – code cast

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.

Code Cast

This is a code cast in Java.

In the first episode we wrote some characterization tests with the purpose to create a basic safety net. Now we continue to refactor the code, starting from there. We already have some tests running and we want to have methods that do only one thing; we want to apply the Single Responsibility Principle. A really good tool that can help is using pure functions. We extract functions, make them static and then make sure the function does not have any side effects. These functions help me clean the code and help me start structurig the code according to clear responsibilities. At a later time we will extract all these functions that have similar responsibilities to a new class.

Read here more about this concept in my blog post.

 

Legacy Coderetreat: Episode 8 – Use Mocking Framework – Code Cast

Use Mocking Framework – code cast

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.

Code Cast

This is a code cast in Java.

In this code cast you can see how to start using mocking framework on an existing code base. Once we have an interface, we can start using the mocking framework to test external dependencies.

After extracting new and clear methods from the messy code and after extracting classes, we now have a code base with clearer dependencies. However, once we understood how to do dependency inversion, testing the core system becomes a bit more difficult. We need to write tests to show how the core system collaborates with the dependencies we inverted. For testing collaboration with inverted dependencies we use mocking framework.

Read here more about this concept in my blog post.