Tag Archives: Code

Evolutionary Design Talk – NewCrafts Paris 18 May 2018

Evolutionary Design Talk

Evolutionary Design: The art of growing a system by observing its natural traits and then normalizing and optimizing its growth

Evolutionary Design seems to be one of the black arts of software development.

Evolution = transformation. Evolving the code is not done by magic, we the programmers evolve the code. And we need specific techniques for that. When we evolve, we transform the code to something else. We will talk about some of these transformations, when to use each one and why.

Simplicity We work feature by feature and not layer by layer. All the development is done on a vertical thin slice through all the layers. We use evolutionary refactoring with many design principles in our mind, but not with a predefined design. We respect the principles, but focus on finding the simplest solution for the problem.

Focus on the problem, not the solution We want to rather focus on the problem and not the solution, rather than when we know the solution, but we just find the fastest way to implement it. When we know the solution, the question is: can it be improved; is it worth it? We will talk about some heuristics of “good enough”.

Video

http://videos.ncrafts.io/video/275530160

Slides

#RemotePairProgramming Ep 009: Adi & Ferdinando – Elastic Pair Programming

About

This is a remote pair programming codecast with Ferdinando Santacroce on the topic of Elastic Pair Programming.

Premise

When you are in a team when people know each other well and they are at the same level, having the role of driver and navigator might not be the best option because the navigator gets bored about the role. In this situation I find both the developers to share keyboard and mice so both can edit the code at anytime, to figure the solution of the problem. So we both can change the code at anytime.

Read More →

#RemotePairProgramming Ep 008: Adi & Tom – Improving Legacy Code

About

After episode 7 when we added the minimum amount of tests needed to start refactoring legacy code, you can see how we gradually improve the code in small steps.

 

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:

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 – Codecast

Document Possible Bugs with Tests – Codecast

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 codecast 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 behavious seemed strange, and we thought they might be bugs.

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

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

Read here more about this concept in my blog post.

When we document defects with tests it is a good idea to group all the tests documenting possible bugs one after the other. The discussions with the business persons are easier and you do not need to search the next test again and again.

Always discuss with business persons before changing the code. Often one might think they understand what the code does, but the situation if often very different in practice. Think to verify every detail with business analysts before changing the existing code.

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

Unit Testing on Legacy Code – Codecast

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.

Codecast

This is a codecast 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.

We started with a class having non-public methods. The purpose of this session was to start covering the class with tests. In this moment we have short and clear unit tests, written in isolation of any slow dependencies. These tests are fast and we need to run then any time we will change the production code, to make sure we do not introduce defects.

In the same way as shown in the last blog posts, we can extract pure functions, extract classes and then cover these classes with unit tests.

Legacy Coderetreat: Episode 11 – Extract Class – Codecast

Extract Class – Codecast

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.

Talk: Wildcard Conference 2013 – Sherlock Holmes and Pairing

Even Sherlock Holmes was pairing. Are you? Let’s find some good practices in the talk below about Sherlock Holmes and Pairing!

During my work I am used to pair with my colleagues on basically anything. I do pair-programming when I develop software, we use pairing when we deliver trainings or when we write articles. I often do remote pair-programming with strangers. The most things I learned during the last years were by working in pair with someone I barely knew.
Pairing for me has the following main advantages:
– I learn a lot from my pair
– I extend my comfort zone and I collaborate better with anyone
– the product we work together is a lot better because four eyes are better than two

Please find examples from the activities of the well-known fictional character Sherlock Holmes on how his pair Dr. Watson helps him become better and finding the answer to their riddles.

 

 
And here are the slides for the talk Sherlock Holmes and Pairing