Final Refractoring Thoughts

Refractoring is nice tool to use, I probably won't use it constantly like I would unit tests but it really does help to clean up code.  Like the other day I ended up writing about 30 if statements in a row for one particular attribute that I was working on.  It ended up being about 200 lines for all of it and would only return a single value back.  I then had to do this two more times for 2 different attributes.  It made the code look terrible and I had no idea where one thing started and the other stopped.  So I used extract method on all three of those things and shoved it into a new file to hold it.  Then again I did extract method on them and then put all of the if statements related to one attribute in its own method.   Stuff like this there really isn't a big deal.  It's more of a stylistic thing and it does help make hard to follow code look way better.  Doing stuff like this doesn't really have an performance gains or hurts the performance of the application so it's not a big deal.

On the other hand, performance is a big deal.  I do believe that if you use extract method several times with small amounts of code in it over a large block of code it hurts performance by a small amount.  But when this code is called constantly and the application depends on it running super fast everything slows down significantly.  There are times when OOP is critical to be used but having ugly code that runs in 0.0000003 seconds compared to 0.01 seconds and it is being called over a billion times, I'd much rather prefer the horrifying looking code than something that is amazing looking but takes forever.  I'd much rather have Windows move files in less than a minute compared to an hour.

Job security is one of the other things that comes to mind.  If you write code that no one else can understand, you are less likely to be fired.  If you have something that looks like it is summing up some data but in reality is just sorting that data and the comments make zero sense, then that is job security.  It doesn't mean that if you write horrible looking code constantly, that could easily be written very nicely, is a good idea.  It just means that if there is some function that ties the whole system together and you are the only one who knows how it works and where to add/remove things that is pretty good.

The book on refractoring does have some really useful ideas for one to use after they have written the code or having to make changes to existing code later.  I know for sure I won't be writing code and then spontaneously decide to "Replace Type Code with State/Strategy".  I'd much rather have the code working perfectly first then clean it up.

This is the last CS 373 blog entry I'm going to write.  So to any hardcore followers, you should know where to find me on the internet.