Refactoring good practices

Refactoring good practices

Refactoring is some kind of restructuring. Technically, it arises from maths, a cleaner technique to show an expression, is to write an equivalence expression by factoring. Refactoring suggests sameness; the first and last products must do exactly the same. In some way it has to do with changing a design once and the same functionality is developed and coded.

The idea of ​​refactoring is to improve the design of an application that is already running. Therefore, it would be a good term redesign, but unfortunately is not very usual. The trouble with refactoring is that it is risky, because we know we are changing code that works with one that, although we presume it will be better quality, we do not know if it will work.


To make sure the refactoring will be safer and less stress, a good practice is to work with automated unit testing, test the changes in an isolated environment, before implement it. Therefore, the refactoring as stated before, try to improve the design of the code already written, its internal structure without changing the observable behaviour. In other words, any client object should realize that something changed. Hence what we are doing is to modify the internal structure of a piece of code without changing its external functionality.


Why refactoring?

Once we have defined what refactoring is, the question that remains is perhaps why we do this. The underlying reasons are:

  • Try to improve the code, making it more understandable and easy to read, taking into account that the times you will read the code will be a lot compared with the times you write a code (only one).
  • We have to be sure that there is not any duplicated code, in order to be sure that each change affects only one portion of the code.
  • This is important, to maintain high quality design.

In other words, we want to control the entropy. The term entropy, originally from thermodynamics, means disorder, a gradual and unstoppable disorder which is reached by inertia and which is very hard to leave. In the case of software, the entropy increase usually occurs when a good design evolves through successful adaptations and becomes incomprehensible and impossible to maintain. And so it is important to keep entropy low to be able to easily do changes, fixes and optimizations. We would want to refactor the code in the following situations:

  • Before we change the existing code
  • Every time after a new functionality is added to the system.
  • Before we try to optimise the design.
  • While the debugs are running.
  • As a result of peer reviews

It is often criticised the practice of refactoring, because in some way we are trying to anticipate to the future needs without knowing whether what we are thinking is correct or not. In fact, the truth is that it does not make any sense to refactor if you will never change the code. And although the code is changed, can I be sure that one hour spend in refactoring ensures at least one hour in the future maintenance? The truth is that there is no way you can guarantee that. However, historical data shows that the vast majority of applications are continually modified, consequently it is a medium term benefit but unfortunately many people avoid it. This is because although it has short-term benefits, the majority of the advantages come in a medium-long term. However, when problems arise, it’s too late to quick solutions, and we must choose more complex alternatives to solve them.

Another problematic arises when we have to deal with the maintenance of an existing application, the most common situation in software development, and usually we argue that we do not have enough time to refactor. However, empirical evidence shows that it is in these cases that suits refactoring, and that time is gained instead of losing it.

On the other hand, there are also people who try to use refactoring as a solution for everything. For instance, people who say that refactoring is an alternative to the previous design. They argue that refactoring allows an incremental design that evolves alongside the code, and it remains in good quality through refactoring. Even though this may apply to small projects, or projects with quite disciplined developers who combines this with other good practices, but it is not the case when these conditions are not met.

Refactoring in a safe way

As it was mention before, the risk of refactoring is high. In fact, we are changing code that is actually working for code that, even though will have a better quality we cannot be sure that it will work. There is a famous quote that says: “If it ain’t broke, don’t fix it” which means that when we are trying to fix something that is working properly, there is a chance that we make new mistakes.


The advice to prevent doing traumatic refactoring are:

  • Do only one step at a time
  • Keep automated tests and run them before to refactor, does not matter how small the change will be. Those can be unit testing, integration testing and functional testing.
  • Use the refactoring tools in the development environment, if any.
  • Program the best, always.
  • Try that the refactoring is made by the person who wrote and debugged the code, or someone accompanied by him.

The main risk about refactoring are big changes or many small changes together, because if something goes wrong, we will never be able to know what caused the failed. Therefore, each refactoring should be small and reversible.


Refactoring tools are always more reliable than a person cutting and pasting code. For a long time there were not too many. But nowadays there are many free development environments that provide good typical refactoring, and there are additional tools also help find problems, proposing refactoring and perform even more complex tasks.

Response Article to Hack and Slash

This post is a response to “Hack and Slash”:


In the original post, the author talks about software engineering, based on the classic book: [The mythical man-month — Frederick. P. Brooks]. He explains the most common failure in software projects, he then describes two typical mistakes, and finally gives his opinion about how to solve them.

One of the assumptions that the author does is that “increasing the number of people will increase the time and cost associated with project, but claiming the opposite would surely seem preposterous” the first thing that I would like to double check, is that when this situation is described in the book, it implies it is a “running software project” increasing manpower to a late software project makes it later.

This then is the altering of the man-month. The number of months of a project rides on its restrictions. The maximum amount of people hinges on the number of autonomous subtasks. Based on the above, schedules can be inferred using less people and more time. But not in the opposite direction, using more people and less time.

The author also mentions that if there are less things to be tested, there is going to be an increase in the productivity, which is completely true. One of the best critics that the book got, was from Capers Jones, who said that: if you focus on improving the software-product quality, the improvement in the productivity will be a natural result. This is based on some reports on the additional cost required in doing troubleshooting because non-contemplated aspects in the design phase.

Although I do agree with the article in general terms, I have to say that the author just mentioned a phrase: “No silver bullet” which is also discussed at the beginning of the book and is in my judgement, one of the most significant. I consider one of the reasons many companies have been successful at agile development philosophies, because they minimize this difficulty is inherent in systems development. The issues of verifying and validating the system are theoretically fewer when after there is some progress analysing, becomes available a rough prototype for the users, in order to know if the project is on solid ground or not.



In every single project that we develop, we need to be measured. Nowadays
customers need to know that what they are buying has the quality they need,
otherwise they cannot use it and they will not buy it. For example, when you are
intended to get a new car, you look for the one that meets the requirements,
while you are doing that, you can check at the measures of every car in order to
know whether it is helpful for you or not.

Software development is not the exception, even though software is
completely different from any other discipline, this means that we
cannot have references from previous work, because every time that
you are developing a new project , the requirements are different,
therefore the time, the resources needed and the cost is going to be
different, software needs to be measured. A customer cannot be sure if
the project has quality or simply solve the main problem unless there
are some measures that evaluate these characteristics, and here is
when the problem arises.


Software Measurements are extracted from data, this is measuring software
processes and source codes, in order to identify areas of the code where you
need to work.
The most common examples of software metrics are the following:
• Lines of code
• Number of classes & interfaces
• Code to comment ratio
• Code coverage
• Bugs to lines of code ratio
• Cohesion
• Coupling
• Failed tests per build
• Version control commits per day
As it was mentioned above, software metrics are a very important
instrument for developing software the main purpose is to let
programmers monitor and control software production, however, it is
very difficult to do it in an accurate way. As it was stated in [1]
“Practitioners want short-term, useful results. Their projects are in trouble
now, and they are not always willing to be a testbed for studies whose results
won’t be helpful until the next project”, it is hard to establish software measures
if we do not have anything to measure indeed. Although it might look insignificant, measurement helps us to see where we are within a project and
hopefully to update our estimates.



Last year I work for a company doing security application and solutions for
banking and government companies, because we are talking about information
security issues, we had to be extremely carefully about compliance and use a
security checklist. Thus, the projects were mostly large-scale software projects.
At the very beginning, the company did not have any methodology for software
measures, as the time went by, the customers started to ask for a way to
evaluate the projects. At this point, the company had to implement a
methodology for the subsequent projects. The first try, it failed because nobody
in the company knew how to follow the methodology.
After some time, the company had to invest resources and time explaining the
personal how to follow and how to execute the methodology.
In most companies this might look as a waste of time and money, because they
do not like to invest without a reason, but the truth is that at the end, you save
more money and increase profits, because in the following projects it was so
much easier to work on the projects while increasing productivity and reducing
costs. And also it was a way to guarantee the customers that the solution meets
the requirements.


Software metrics are usually used to measure some aspects associated with
software development. These aspects may include estimation, detection and
prevention of issues, product assessment, etc. Their utilization within a
measurement framework and the use of automated tools can help towards
development process control and higher quality software.



[1] S.L. Pfleeger, R. Jeffery, B. Curtis, B. Kitchenham. “Status Report on Software
Measurement.” IEEE Software, March/April 1997
[2] R.J. Offen, R. Jeffery.” Establishing Software Measurements Programs”, IEEE Software,
March/April 1997.