Tag Archives: Design

TDD as if you Meant It: Refactor Primitives to Concepts (Episode 3)

TDD as if you Meant It: Refactor Primitives to Concepts (Episode 3)

About

Hidden Concepts

Each primitive is always hiding a business concept (or call them Domain Entities if you wish). During this episode these primitives will get better names (“Maximize Clarity” from the Four Elements of Simple Design) and when I see duplication between them, it will be removed (“Minimize Duplication” from the Four Elements of Simple Design).

Whenever these concepts remain hidden, the cost of change is big. The more hidden design concepts we have, the bigger the cost of change. I optimize my code for fast and cheap changeability. Because this example is written using Object Oriented Programming concepts, each of these concepts needs at the end to become a class.

Classical Evolutionary Design Layers

The business concepts grow in layers from: primitives, to variables, methods and then classes. With TDD as if you Meant It we always use the rule of three when evolving from one layer to another. I always use refactorings to make duplication explicit and then minimize it. I never skip a layer, because that would be a much too bigger step. We could call this approach Evolutionary Design in Baby Steps.

This approach is useful when starting bottom-up, when there are no, or not may classes and methods, but tests. This approach would not be suitable usually when having a top-down approach.

Read More →

TDD as if you Meant It: I care about Behavior and not about Representation (Episode 2)

TDD as if you Meant It: I care about Behavior and not about Representation (Episode 2)

About

Intentional Primitive Obsession

In the first episode I added some tests where I represent state as strings. This is an intentional approach to hide the complexity of the concepts with primitives. Since with TDD as if you Meant It I am not allowed to add any new classes, I need to start the problem by using primitives. I could have used an array to define the Board concept, but that already means that I am taking more complex design decisions.

Triangulating

I am focusing on triangulating on the concept of GameResult in order to have enough proof in order to extract it to a method. The typical proof I am searching for is duplication. I apply the Rule of Three to spot duplication and then to generalize my code.

Deductive vs Inductive

When doing evolutionary design I am deductive or inductive.
Inductive: I start from small concepts and I generalize them. Whenever I can can generalize some higher order concepts from the code I have, I extract them. These higher order concepts are usually a crystallization of the raw primitives.

Deductive: when doing design up-front I am deductive. I start from some bigger idea and then I try to prove it with code.
Read More →

TDD as if you Meant It: Think – Red – Green – Refactor (Episode 1)

TDD as if you Meant It: Think – Red – Green – Refactor (Episode 1)

About

TDD as if you meant it is a very strict way of writing code in a Test Driven Development approach. One needs to follow the rules below:

Guidelines

In the first episode the main focus in to respect a few guidelines:

  1. Guideline 1: Always start with outputs when doing an analysis
  2. Guideline 2: Behavior Slicing
  3. Guideline 3: SIMPLIFY!
  4. Guideline 4: Introduce only one notion (domain concept) at a time, one per test
  5. Guideline 5: The rule of three “only extract duplication when spotted at least three times”
  6. Guideline 6: Triangulation

Read More →

Evolutionary Design: Normalize Growth

Evolutionary Design: Normalize Growth

The Definitions

Evolutionary Design is the practice of creating the components and interactions of a system while it is evolving, on the basis of the client requirements and user needs.

Normalization refers to a process that makes something more normal or regular

Normalization may refer to more sophisticated adjustments where the intention is to bring the entire probability distributions of adjusted values into alignment from Wikipedia

Growth refers to a positive change in size, and/or maturation, often over a period of time from Wikipedia

 

The Moment

I am a big fan of gardening. Whenever I can, I take care of my plants and think about subjects like Evolutionary Design. One moment I was taking care of my young tomato plants: I needed to rip the small leaves that grow and just take the food away from the flowers and fruits. And it struck me: any gardener is doing Evolutionary Design.

pruning

Read More →

Talk: Easier to change CODE

Talk: Easier to change CODE

This is a talk from I T.A.K.E. Unconference 2016, Bucharest.

It is a hands-on talk, where I refactor some code live with the help of the audience.

Techniques

During this talk you will see techniques that are useful for tackling legacy code issues. You will be able to see how, with the help of the audience, the code can be improved to become easier to change. We want to change existing code in just a few situations: solve bug, add feature, improve the testability of the system. Remember that when you change existing code you understand what is the reason to do this.

Before changing the code is important to have some tests as a safety net. For that I am using Characterization Tests. Only after having these characterization tests, we can start to refactor the code, but with care in order not to introduce defects. Even though we have a safety net, it is not enough and bugs might appear. So to make sure we have more trust in tests the first refactoring steps are made with the purpose to be able to add unit tests.

Adding unit tests gives me better quality feedback, because if I introduce a defect I will know better what I have done wrong. A characterization test is too big, and I might need to dig a while to find the reason.

Changing legacy code needs to be done with care, in small steps and try to always remain with the tests on green. The longer I stay on red, the riskier is that I introduce defects and I lose my refactoring direction.

Easier to change CODE means the total opposite of the Legacy Code is Fear concept. I have my toolbox with legacy code techniques. I know how to use them,  and so I am able to make the code to be easier to change.

Video

 

Talk: Java User Group Łódź – Legacy Code is Fear

Talk: Legacy Code is Fear (Łódź, Poland)

Legacy code is fear because we fear the unknown. Learn what you need to learn in order to be less scared about legacy code during this talk.

This is a talk from last year, before Global Day of Coderetreat Lodz.

You are a programmer. Someone from the company comes with an idea to add a feature and they are sure this new feature is very easy to add. And it should be. But the code is old. The code is a mess. Nobody in the firm knows any more that part of the system. You need to change that ugly piece of code. You are afraid that you might introduce defects. Legacy code is fear.

This talk is about how our unknowns make us feel frightened. We need to get passed that and learn techniques, practice them, understand how and when to use them. Only with more knowledge we will be able to tackle legacy code. But how do we acquire knowledge? We need to read, try, experiment, fail, and many more with some learning code base. Then we need do the same with production code. My advice is to never try these legacy code techniques on your legacy code base at work. You will be disappointed in the beginning because they will be difficult to apply. That is why it is important to start small, with an easier to understand code base in order to learn. And only after you can refactor that simpler code base, it is the time to start using the legacy code techniques on the bigger code base from work.

 

Here are the slides for the talk:

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 →

Talk: Agile Lean Europe 2014 – Legacy Code is Fear

Legacy code is fear because we fear the unknown. Learn what you need to learn in order to be less scared about legacy code during this talk.

You are a programmer. Someone from the company comes with an idea to add a feature and they are sure this new feature is very easy to add. And it should be. But the code is old. The code is a mess. Nobody in the firm knows any more that part of the system. You need to change that ugly piece of code. You are afraid that you might introduce defects. Legacy code is fear.

 

Here are the slides for the talk Legacy Code is Fear:

Legacy Coderetreat: Part 11 – Refactoring Rule of Three

Rule of Three

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

The rule of three says:

Extract duplication only when you see it the third time.

This concept is extremely useful when you want to improve legacy code, refactor in the TDD cycle or just improve existing code that is covered by tests.

The Rule of Three brings higher coherence and more clarity to the system, because the duplicated code starts to be moved into specialized areas. In this way we optimize the code base for changeability.

The Rule of Three prevents from prematurely extracting possible duplication and defers the duplication minimization until we have enough proof.

minimize-duplication

Read More →

Legacy Coderetreat: Part 9 – Use Mocking Framework

Use Mocking Framework

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

By using mocking frameworks we are writing short and easy to read tests. The duplication of test doubles written by hand is minimized by the use mocking framework.

mocking-framework

Read More →