Continuous Refactoring

From WikiContent

(Difference between revisions)
Jump to: navigation, search
(New page: == Ruthless refactoring == Code bases that are not cared for tend to take the same route as a compost heap. They rot. Every line of code that is written starts to age at the moment of its...)
(Ruthless refactoring)
Line 4: Line 4:
Due to limited information at the time of writing, newly written code is mostly an inappropriate solution for the problem. First you get it to solve the problem.
Due to limited information at the time of writing, newly written code is mostly an inappropriate solution for the problem. First you get it to solve the problem.
-
Try using TDD for validating that your problem is solved. But you shouldn't stop there. The TDD mantra is red-green-refactor.
+
Try using ''test driven development'' (TDD) for validating that your problem is solved. But you shouldn't stop there. The TDD mantra is red-green-refactor.
So after solving your problem you must look at your code base from a wider perspective. How does it fit with your systems architecture, the programming model principles (e.g. object oriented, functional, etc.), the language idioms.
So after solving your problem you must look at your code base from a wider perspective. How does it fit with your systems architecture, the programming model principles (e.g. object oriented, functional, etc.), the language idioms.
-
Can you see any code smells like
+
Can you see any ''code smells'' like
* duplication (near and far),
* duplication (near and far),
* inconsistent or uninformative names,
* inconsistent or uninformative names,
Line 15: Line 15:
* long sequences of conditionals
* long sequences of conditionals
* working in the intestines of other units (objects, modules)
* working in the intestines of other units (objects, modules)
-
* exposing your internal state
+
* exposing your internal state?
-
Your IDE may help you with this. The code intentions they provide offer a good starting point as they are tailored to the language and sometimes offer quick fixes (Dubbed refactoring by example by Kent Beck).
+
Your IDE may help you with this. The code intentions they provide offer a good starting point as they are tailored to the language and sometimes offer quick fixes (Dubbed ''refactoring by example'' by Kent Beck).
If so you have to take action. Try to convert the smelling code to good looking pieces that feel just right. Don't rush. Just take small steps. And keep your tests running so that you can easily see if you broke something. In the Refactoring book the steps of the discussed refactorings are outlined in great detail, so its easy to follow. I would suggest to do the steps at least once manually to get a feeling for the preconditions and side effects of each refactoring. Thinking about what you're doing is absolutely necessary when refactoring. Small glitches can become big deals as you can impact quite a part of the code base.
If so you have to take action. Try to convert the smelling code to good looking pieces that feel just right. Don't rush. Just take small steps. And keep your tests running so that you can easily see if you broke something. In the Refactoring book the steps of the discussed refactorings are outlined in great detail, so its easy to follow. I would suggest to do the steps at least once manually to get a feeling for the preconditions and side effects of each refactoring. Thinking about what you're doing is absolutely necessary when refactoring. Small glitches can become big deals as you can impact quite a part of the code base.
Line 25: Line 25:
Another great way to look for the target of your refactoring is design patterns. Although the original work by Martin Fowler et.al. does not rely on design patterns that heavily the additional work of Joshua Kerievsky does a good job in discussing design patterns as goals for refactorings.
Another great way to look for the target of your refactoring is design patterns. Although the original work by Martin Fowler et.al. does not rely on design patterns that heavily the additional work of Joshua Kerievsky does a good job in discussing design patterns as goals for refactorings.
-
Fortunately in our time we have the tools available to help us with automatic refactoring. Most IDE offer a impressive range of refactorings that work on the syntactically sound parse tree of your source code (and so can even refactoring partially defect or unfinished sourceode). So there is no excuse of not refactoring.
+
Fortunately in our time we have the tools available to help us with automatic refactoring. Most IDE offer a impressive range of refactorings that work on the syntactically sound parse tree of your source code (and so can even refactoring partially defect or unfinished sourceode). So there is no excuse for not refactoring.
 +
 
 +
When refactoring you often encounter an epiphany at some point. This happens when suddenly all puzzle pieces fall into the place where they belong and the sum of your code is bigger than its parts. From that point it is quite easy to take a leap in the development of your system or it's architecture.
-
When refactoring you often encounter an epiphany at some point. This happens when suddenly all puzzle pieces fall into the place where they belong and the sum of your code is bigger than its parts. From that point it is quite easy to take a leap in the development of your system or its architecture.
 
--[[User:Michael Hunger|Michael Hunger]] 18:25, 22 January 2009 (PST)
--[[User:Michael Hunger|Michael Hunger]] 18:25, 22 January 2009 (PST)

Revision as of 00:24, 27 January 2009

Ruthless refactoring

Code bases that are not cared for tend to take the same route as a compost heap. They rot. Every line of code that is written starts to age at the moment of its creation. Due to limited information at the time of writing, newly written code is mostly an inappropriate solution for the problem. First you get it to solve the problem.

Try using test driven development (TDD) for validating that your problem is solved. But you shouldn't stop there. The TDD mantra is red-green-refactor.

So after solving your problem you must look at your code base from a wider perspective. How does it fit with your systems architecture, the programming model principles (e.g. object oriented, functional, etc.), the language idioms.

Can you see any code smells like

  • duplication (near and far),
  • inconsistent or uninformative names,
  • long pieces of code
  • unintelligible boolean expressions
  • long sequences of conditionals
  • working in the intestines of other units (objects, modules)
  • exposing your internal state?

Your IDE may help you with this. The code intentions they provide offer a good starting point as they are tailored to the language and sometimes offer quick fixes (Dubbed refactoring by example by Kent Beck).

If so you have to take action. Try to convert the smelling code to good looking pieces that feel just right. Don't rush. Just take small steps. And keep your tests running so that you can easily see if you broke something. In the Refactoring book the steps of the discussed refactorings are outlined in great detail, so its easy to follow. I would suggest to do the steps at least once manually to get a feeling for the preconditions and side effects of each refactoring. Thinking about what you're doing is absolutely necessary when refactoring. Small glitches can become big deals as you can impact quite a part of the code base.

Ask for help if your gut feeling does not guide you in the right direction. Take a co-worker and pair with him for the refactoring session. Two sets of eyes and experiences have a really great impact - especially if one of these is unclouded by the initial implementation approach.

Another great way to look for the target of your refactoring is design patterns. Although the original work by Martin Fowler et.al. does not rely on design patterns that heavily the additional work of Joshua Kerievsky does a good job in discussing design patterns as goals for refactorings.

Fortunately in our time we have the tools available to help us with automatic refactoring. Most IDE offer a impressive range of refactorings that work on the syntactically sound parse tree of your source code (and so can even refactoring partially defect or unfinished sourceode). So there is no excuse for not refactoring.

When refactoring you often encounter an epiphany at some point. This happens when suddenly all puzzle pieces fall into the place where they belong and the sum of your code is bigger than its parts. From that point it is quite easy to take a leap in the development of your system or it's architecture.

--Michael Hunger 18:25, 22 January 2009 (PST)

Personal tools