A cluster of parameters often indicates an object in hiding. By creating a Parameter Object, you are making the code more flexible and you may discover a new object that was hiding in plain sight. In many cases, not only will you end up moving the parameters into a class, but you very well may discover that some of your code will move into the class as well. In this way, parameter clusters can be an indication we have a Single Responsibility Problem.
Dealing with a large, undocumented codebase
I was recently asked to answer the somewhat vague question, “How do you interact with a large undocumented code base?”
One small step at a time.
A large code base can be overwhelming. Rather than trying to get to know the whole thing, I tend to focus on the problem at hand.
Removing Code Duplication
Today’s offering is another post inspired by a question on Quora about when to refactor away duplicate code.
The specific question was, “What is the limit for duplicate code to start refactoring?”
I took this to mean, “How much duplication needs to exist before you should refactor it?”
And I’m not sure that’s really a great question. So I decided to start with clarifying what duplication needs to be cleaned up and then when might that happen.
When to Refactor Your Code
For me, refactoring is when we change the implementation of a piece of code without changing the behavior. That’s the entire definition - Change the implementation, but not the behavior.
As a result, I will generally not refactor code unless it has a solid set of tests around it. If I see code that needs refactoring, but has insufficient tests, I will add character tests.
Refactor - You Keep Using That Word…
I stumbled upon a thread recently where the question was posed, “What are some common mistakes when refactoring code?”
The answers were interesting. The more I read, the more I realized that folks weren’t talking about the same thing. They were all saying “refactor”, but many were describing scenarios that sounded more like a rewrite rather than a refactor. This is not uncommon. I’ve encountered this on multiple forums, in slack discussions, in blog posts, and in actual human to human conversation (it happens).
Collapsing Conditionals
Thoughts on Refactoring
I recently worked with a team on a fairly significant refactoring. I paired with different team members each day over a three day period as we moved code around, pushing responsibility into other classes, reducing complexity, and make the code more expressive. On the fourth day, I put together some notes on the things we saw and general guidelines for the team to keep in mind. Nothing herein is new to the community, but it might be new to you.
Code Profiling
I recently gave a talk on the role of a Quality Analyst as an organization transitions from waterfall to agile. The talk was entitled "Switching Horses in Midstream" and covered a number of topics. One item in particular struck me as worthy of blogging about. It's a technique I've been using for years, but have never written about it. So here we go:
Legacy code bases with a lack of test coverage are often trepidatious places to hang out. You never know when a simple abstract method is going to create a sink-hole of logic and reason, eventually leading to your exhausted resolve to revert and leave it dirty.
"Necessary" Refactoring
In a discussion on the Agile Alliance Linked In Group, Michael Moles asked how refactoring fit into the agile process.
The Question
Refactoring: How does it fit into your Agile process?
We are in the midst of writing a new product, at this point the developers are realizing that some of the code should be refactored to improve performance and or clarity for ease of use. How do you fit refactoring into you Agile process? We have created separate backlog items for refactoring specific pieces of code. These backlog items are treated exactly like any other backlog item (meaning they have effort assigned and are committed to sprints by the team). What do you do when refactoring is necessary?