Tag Archives: Design

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.

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

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

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

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:

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 →

Legacy Coderetreat: Part 8 – Extract and Override

Extract and Override

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

Almost always when needing to test existing code we bump against dependencies that make the system untestable. This technique is useful to extract the static dependencies. After that we can use dependency inversion in order to be able to really test the systems.

With this technique we can transform untestable systems into testable systems, step by step. The steps are small because we want to enable safety while changing the code.

Extract and Override

Extract and Override

Read More →

Legacy Coderetreat: Part 7 – Dependency inversion

Dependency Inversion

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

As you found out from the previous post, it would be a good idea to refactor in a safe way. This session is about another concept that will prepare for the tough refactorings ahead.

Dependency inversion is one way of transforming a tightly coupled system into a system that has a core and many small external dependencies. These external dependencies can be called also plugins.

Sierpinski_Racket_example Read More →