Refactoring – if it ain’t broken, don’t fix it

Refactoring – if it ain’t broken, don’t fix it

on Oct 14, 10 • by Alen Zukich • with 1 Comment

I recently read a book by Peter Ritchie called “Refactoring with Microsoft Visual Studio 2010” and thought I would give my review. Great book to really help you get started with Refactoring.  Ritchie first goes into an introduction of refactoring and some of the tools available in Visual Studio 2010.  He...

Home » Code Refactoring » Refactoring – if it ain’t broken, don’t fix it

I recently read a book by Peter Ritchie called “Refactoring with Microsoft Visual Studio 2010” and thought I would give my review.

Great book to really help you get started with Refactoring.  Ritchie first goes into an introduction of refactoring and some of the tools available in Visual Studio 2010.  He then provides techniques to help you identify code that might need to be refactored along with examples and step by step procedures to refactor the code.

The focus of this book is not necessarily with Visual Studio 2010, as many of the refactoring examples he goes through do not even have a solution with Visual Studio, but more with a focus on C# code.  When I first ordered this book it wasn’t entirely clear to me that C# was the only language of focus.  That was a little bit disappointing for me because at Klocwork our focus is on refactoring for C/C++.  I guess I’m not surprised as not too many tools are providing a refactoring solution for C/C++ developers.  But with that said even though all examples are C#, what it really helps you understand is where and when to refactor and that is language independent.

I think Ritchie really describes the question of “why refactor” brilliantly.  The point of refactoring vs. rewriting is to fix something that’s not broken.  But as Ritchie states, he is a believer in if it ain’t broken, don’t fix it, but unless your code base defies all reality, it is likely that your code is constantly evolving and getting more complex.  Hence the need to refactor.

Another important point made by Ritchie is that refactoring falls into the developer’s hands.  It is not a task that keeps building up until you identify numerous backlog’s of refactoring.  It is something you need to do daily, as needed.

Overall I enjoyed the detail and examples provided and recommend it to any.  I hope to talk a little more on how Ritchie relates metrics to refactoring in another post.

Related Posts

One Response to Refactoring – if it ain’t broken, don’t fix it

Leave a Reply

Your email address will not be published. Required fields are marked *

*

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

Scroll to top