Refactoring

Hello,

I have been reading Pragmatic Programmer which is my one of the favorite book. I will share the ideas of refactoring. Let's start.

I am going to touch on refactoring in software development in this post. I am going to mention my job experiences which are good examples of refactoring.

Construction or gardening?

Software construction is an old-style common term in software development.

1. - Decide what you want to build. Draw up a blueprint.
2. - Build the superstructure, and apply finishing touches.
3. - Move in and call for building maintenance to fix any problems.

Building a software doesn't work that way. Gardening is more organic than construction. It requires water, sun, compost or any related thing which are required for life. It also implies changes in gardening. We always work, think and be careful. So software is similar to gardening. We need to work well and write good code in terms of product quality.

Le's define what refactoring is according to Uncle Bob:

Rewriting, reworking and re-architecting code are collectively known as refactoring.

When do we refactor?

1. Experience engineer to newbie engineer sometimes we duplicate our code which is not a good practice at all. It is against to DRY principle. Don't Repeat Yourself.
2. The code can change according to our knowledge and our technology. Keeping up is a good practice. It solves the security problems and performance which come up in the future. (Outdated knowledge)
3. When we want a readable and clean code we need to refactor our code. I can be the design of the code.

Refactor Early, Refactor Often...

Real World Scenario

Me: Hi boss. I finished the ABC module which is quite hard. The code works but I need another week to refactor it.

Boss: Hi Erol. Let me test this module so I can understand if it works well. Hmm. Well done. The code seems to work well and we are going to have a demo on Friday to a client. Our time is limited. Deploy it to the server.

Me: Ohh. For sure I am going to make it.

About two weeks later:

Me: Seriously? This code seems like a spaghetti code. I am really bored. I need to have a break and time to refactor it. Truth is there are tons of jobs that I really have to care. On the other hand, I have a god class, ugly code which is not functional and modular.

Boss: Erol. Do you remember that you have done module from last week? It worked when we present to a client but the problem is we found a bug. As you know bug-fix is an important issue. We don't want to bother our customer in the production env. Could you give up your current task and figure out the problem?

Me: I am sorry to hear that. Sure I will take a look at it. After about 5 minutes I will have done it and deploy to the production server.

So, unfortunately, we have a cycle between two of us. We have the stumbling block. We lost our valuable time.

What does R.Martin suggest?

"You might want to explain this principle to the boss by using a medical analogy: think of the code that needs refactoring as a “growth.” Removing it requires invasive surgery. You can go in now, and take it out while it is still small. Or, you could wait while it grows and spreads—but removing it then will be both more expensive and more dangerous. Wait even longer, and you may lose the patient entirely." - Pragmatic Programmer

We had a communication a problem and time excuse to refactor in coding. As a programmer who read the book Pragmatic Programmer, I suggested the idea of Uncle Bob. My boss is quite fine when hears the thoughts.

I try to write my code. I do my tests until I see green. (TDD) Then I do refactoring in coding. After than that, I write code for production code.  I let my boss how much time it takes. So he/she can give a deadline for the client.

Check out the links about refactoring. Let me know what do you think.

https://www.youtube.com/watch?v=y4_SJzNJnXU

https://www.youtube.com/watchv=vhYK3pDUijk&list=PLGLfVvz_LVvSuz6NuHAzpM52qKM6bPlCV

Important terms:

Software Rot, Code RotSoftware Entropy