When to refactor code
mikemainguy.blogspot.com
mikemainguy.blogspot.com
http://confreaks.com/videos/2333-mwrc2013-work-play-code
Also, if you don't have a test suite to prove your refactoring didn't change functionality, IMO you aren't refactoring, you are simply rewriting. This is the point many people miss about TDD. TDD is first and foremost about letting you refactor your code; doing TDD right gives you the best environment for writing great code. On the other hand, doing TDD wrong makes it more likely your entire code base will be very difficult to maintain.
Modular code tends to have fewer dependencies and tends to produce fewer side effects. All of these things make for code which is generally easier to maintain and modify, easier to understand, easier to debug, and easier to reuse. All of which tend to lead to higher code quality naturally.
A high level of unit test coverage also gives you other benefits, of course, but I thought I'd highlight these side benefits because they are perhaps the most important.
Anyway, I don't think you need a big, complicated checklist like this. Writing code by checklist is not going to solve your problems. The more important questions are these:
- Do you find yourself spending more time than you think you should making changes and additions (or bug fixes) to the same sections of code?
- Do you often run into difficulty figuring out or remembering what a given section of code does?
If either of those things are true then refactoring might be a good idea. Use extract method until it hurts. Use extract method on complicated logic tests as well. Figure out where the control flow is wonky and switch to using flow based on method calls and returns to simplify things. Be ruthless. Don't be lulled into the "meaty method" trap, don't be afraid of short methods, even if they're only one line. Make your code so that it looks almost too simple, as though even a novice could look at it and tell you what it does. Push until you get to a state where making changes seems almost like cheating because it's so easy. That's when you know you're in the sweet spot. Programming is about making things easier, even future programming, not about proving how incredibly skilled you are at maintaining complex code.
This is especially crucial when you break up your code in a myriad of small functions/methods: the whole point of refactoring was to make them readable, which means small and self contained —you don't want to keep a gazillion dependencies in mind while reading and testing a given method. Avoiding side effects is a big help there, because it will make your interfaces more explicit, and your dependencies more visible.
1. Create a new class for the computation
2. Define a method on that class to do the new work.
3. Copy the body of the old method over, and change variable references to instance variables.
4. Give it an initialize method that takes arguments to set the instance variables used in step 3.
5. Make the old method delegate to the new class and method.
I'm not sure if this is the _best_ example, but I wrote about this a few years ago, in Ruby: http://blog.steveklabnik.com/posts/2011-09-06-the-secret-to-...
> "this 10 item checklist."
> 11 items in the checklist
If the last developer named his or her variables along the lines of 'a', 'b', 'c', you're damn right I have an issue with their naming convention and I'm going to fix it.
Seems confusing that answering "No" to this (meaning you did NOT know what cyclomatic complexity was) would be a net positive for refactoring?