In one of my last articles, I was writing about improving names in the project. One of the tips was tell what pattern you use. Then I read a newsletter from Sandi Metz “Don’t Name Classes After Patterns. Mostly.” which have a different opinion about patterns in names. I think it is a good topic to write about it. There is no one silver bullet rule on how to do programming or create names. We have some tips, but those are the signpost. There are always some pros and cons, so it is good to have a wider perspective.

As developers, we are often talking about high-level architecture. I mean DDD, hexagonal architecture, and so on. We want to introduce those concepts to our project. We want to do that now! The new concept, new architecture, new language, new framework. We fall into a trap. Technical news is for us like drugs. We want more and more. And we don’t think about the consequences. The goal is noble. We want to have a good quality project which can easily adjust to new requirements. Unfortunately, the way we do that is not always the best. We need evolution, not revolution. We need small, conscious steps. Today I would like to discuss one of those kinds of steps. Very important and also very hard. I would like to talk with you about naming thing.

I think every programmer, at least at some point, wanted to resolve some big problems, focus on big architecture and be the one, who will fix the entire world. Did you ever feel that way? I did, more than once. It’s funny because at that moment I feel that I can change application completely, for the better of course ;] I can do some refactoring here and there. I can do that alone, without any help. I see the solution inside my head. It is almost done. But after this moment of excitement, I know that this is a daily base work. To have good architecture, we need to take care of each small line of code. This will not happen by night. It is hard work and sometimes we forget about it. It is much more fun to think about integration with Google Earth Engine then about naming of one small variable. Don’t you think?

Last time in the article Ruby Refactoring step by step - part 1 we went through the very procedural code in one class to a more object oriented approach. This time we will continue our journey through refactoring. We will cover small object instead of one big class and we will use composition to plug behavior into an object. Let’s start!

Refactoring is one of my favorite topics. I love to clean up things in real life and also in code. I’ve worked and I’m still working on web application projects. And I look for answers on how to write good code. What are the reasons that after some time our code is messy and not readable? So day by day I learn how to refactor code in a good way based on my experience and the experience of others. Today I would like to share an example of refactoring with you.

I had situation where I worked with many different (but in some way similar) collections in Ruby. This collections had very similar methods to search elements by name. In this particular example I decided to use lambda. Let me show you how this looks like.

A few weeks ago, I worked on one controller class in the Rails app. When you see this code, you can say, it’s pretty OK. It’s quite short, readable, just fine. But there is a bug in this code. You can overlook it at the very beginning. Because I had this bug and I needed to change the class anyway, I decided to do refactoring here. Let’s checkout the full process.

This time I will change Ruby code. I wrote this a “little monster” code but it’s terrible. I must do something with it. OK, lets start from the beginning…

This will be the first article about refactoring. I love refactoring, so let’s start. I think that the best way to do this is to put some code on the beginning and then change it. Today I would like to show you a piece of CoffeeScript code…