Starting a section about refactoring and it's impact on software quality.

[ifi-stolz-refaktor.git] / thesis / master-thesis-erlenkr.tex

\documentclass[USenglish]{ifimaster}
\usepackage{import}
\usepackage[utf8]{inputenc}
\usepackage[T1]{fontenc,url}
\urlstyle{sf}
\usepackage{babel,textcomp,csquotes,ifimasterforside,varioref,graphicx}
\usepackage[style=numeric-comp]{biblatex}
%\usepackage[backend=biber,style=numeric-comp]{biblatex}
\usepackage{amsthm}

\theoremstyle{plain}
\newtheorem*{wordDef}{Definition}

\newcommand{\definition}[1]{\begin{wordDef}#1\end{wordDef}}


\title{Refactoring}
\subtitle{An essay}
\author{Erlend Kristiansen}

\bibliography{bibliography/master-thesis-erlenkr-bibliography}

\begin{document}
\ififorside{}
\frontmatter{}


\chapter*{Abstract}
Empty document.

\tableofcontents{}
\listoffigures{}
\listoftables{}

\chapter*{Preface}

\mainmatter{}

\part{Introduction}

\chapter{Refactoring in general}

\section*{What is refactoring?}

This question is best answered dividing the answer into two parts. First 
defining the concept of a refactoring, then discuss what the dicipline of 
refactoring is all about. And to make it clear already from the beginning: The 
dicussions in this report must me seen in the context of object oriented 
programming languages. It may be obvious, but much of the material will not make 
much sense otherwise, although some of the techniques may be applicable to 
sequential languages, then possibly in other forms.

\subsection*{Defining a refactoring}
Well, this is the easy one.
\definition{A refactoring is a transformation
done to a program without altering its external behaviour.}
So a refactoring changes how the \emph{code} of a program is percepted by the 
\emph{programmer}, and not the behaviour experienced by any user of the program.  
The semantic meaning is preserved. To \emph{refactor} is (quoting Martin Fowler)
\begin{quote}
  \ldots to restructure software by applying a series of refactorings without 
  changing its observable behaviour. \cite{refactoring} % page 54, definition
\end{quote}

\subsection*{The dicipline of refactoring}
This one is a little harder. To get a grasp of what the dicipline of refactoring 
is about, we better answer this question: \emph{Why do people refactor?} 
Possible answers could include: ``To remove duplication'' or ``to break up long 
methods''.  Practitioners of the art of Design Patterns \cite{dp} could say that 
they do it to introduce a long-needed pattern to their program's design. So it's 
safe to say that peoples intentions is to make their programs \emph{better} in 
some sense. But what aspects of the programs are becoming improved?

As already mentioned, people often refactor to get rid of duplication. Moving 
identical or similar code into methods, and maybe pushing those around in their 
hierarchies. Making template methods for overlapping algorithms and so on. It's 
all about gathering what belongs together and putting it all in one place.  And 
the result? The code is easier to maintain, due to removing the implicit 
coupling between the code snippets and getting rid of the almost sure path to 
bugs.

The same people find out that their program contains a lot of long and 
hard-to-grasp methods. Then what do they do? They begin dividing their methods 
into smaller ones, using the \emph{Extract Method} \cite{refactoring}. All of a 
sudden they may discover something about their program that they weren't aware 
of before; revealing bugs they didn't know about or couldn't find due to the 
complex structure of their program. Making the methods smaller and giving good 
names to the new ones clarifies the algorithms and enhances the
\emph{understandability} of the program.  This makes simple refactoring an 
excellent method for exploring unknown program code, or code that you had 
forgotten that you wrote!

The word \emph{simple} came up in the last section. In fact, most basic 
refactorings are simple. The true power of them are revealed first when they are 
combined into larger --- higher level --- refactorings. Often the goal of such a 
serie of refactorings is a design pattern. Thus the \emph{design} can be evolved 
throughout the lifetime of a program, opposed to designing up-front. It's all 
about being structured and taking small steps to improve the design.

Many refactorings are aimed at lowering the coupling between different classes 
and different layers of logic. Say for instance that the coupling between the 
user interface and the business logic of a program is lowered. Then the business 
logic of the program could much easier be the target of automated tests, 
increasing the productivity in the software development process. It would also 
be much easier to distribute the different parts of the program if they were 
decoupled.

Another effect of refactoring is that with the increased separation of concerns 
coming out of many refactorings, the \emph{tunability} is improved. When 
profiling programs, the problem parts are narrowed down to smaller parts of the 
code and optimization can be performed only where needed.

Refactoring program code --- with a goal in mind --- give the code itself more 
value. That is in the form of robustness, understandability and maintainability.  
With the first as an obvious advantage, but with the following two being also 
very important in software development. By incorporating refactoring in the 
development process, bugs are found faster, new functionality is added more 
easily and code is easier to understand by the next person exposed to it, which 
might as well be the person who wrote it. So, refactoring can also add to the 
monetary value of a business, by increased productivity of the develompment 
process in the long run.


% \part{The project}                    

% \chapter{Planning the project}       


%\part{Conclusion}                    

%\chapter{Results}                   



\section*{The impact on software quality}

\subsection*{What is meant by quality?}
The term \emph{software quality} can have many meanings. It all depends on the 
context we put it in. If we look at it with the eyes of a software developer, it 
usually mean that the software is easily maintainable and testable, or in other 
words, that it is \emph{well designed}. This often correlates with the 
management scale, where \emph{keeping the schedule} and \emph{customer 
satisfaction} is at the center.  (Although refactoring isn't always recognized 
as the best way to achieve these goals.) From the customers point of view, in 
addition to good usability,
\emph{performance} and \emph{lack of bugs} is always appreciated, measurements 
that are also shared by the software developer. (In addition, such things as 
good documentation could be measured, but this is out of the scope of this 
document.)

\subsection*{The impact on performance}
\begin{quote}
  Refactoring certainly will make software go more slowly, but it also makes the 
  software more amenable to performance tuning. \cite{refactoring} % page 69
\end{quote}
There is a common belief that refactoring compromises performance, due to 
increased degree of indirection and that polymorphism is slower than 
conditionals.

In a survey, Demeyer \cite{demeyer2002} disproves this view in the case of 
polymorphism. He is doing an experiment on, what he calls, ``Transform Self Type 
Checks'' where you introduce a new polymorphic method and a new class hierarchy 
to get rid of a class' type checking of a ``type attribute``. He uses this kind 
of transformation to represent other ways of replacing conditionals with 
polymorphism as well. The experiment is performed on the C++ programming 
language and with three different compilators and platforms. Demeyer concludes 
that, with compiler optimization turned on, polymorphism beats middle to large 
sized if-statements and does as well as case-statements. (In accordance with his 
hypethesis, due to similarities between the way C++ handles polymorphism and 
case-statements.)
\begin{quote}
  The interesting thing about performance is that if you analyze most programs, 
  you find that they waste most of their time in a small fraction of the code.  
  \cite{refactoring}
\end{quote}
So, although an increased amount of method calls could potentially slow down 
programs, one should avoid premature optimization and sacrificing good design, 
leaving the performance tuning until after profiling the software and having 
isolated the actual problem areas.


\backmatter{}
\printbibliography
\end{document}