At some point in creating your plugin, you’ve probably run into situations when you feel like you’re writing dirty or “bad” code.
This is totally normal and a part of every-day software engineering.
It’s okay to write initially dirty code, but you must acknowledge that not getting back around to cleaning it up will actually cost you more time in the long run.
I really like how Refactoring Guru puts it in the Rule of Three:
1. When you’re doing something for the first time, just get it done
2. When you’re doing something similar for the second time, cringe at having to repeat but do the same thing anyway
3. When you’re doing something for the third time, start refactoring
When you apply bugfixes that needs to be released, sometimes the urgency of the need prevents you from taking the time to develop it cleanly.
Unfortunately, most engineers never get back around to cleaning up code and refactoring properly.
Refactoring code is often seen as wasted time
“I can’t spend time refactoring this, I need to get this fix out to users today”
Some other reasons preventing engineers from refactoring:
- No process for automated testing
- Pressure from managers or paying users
- No monitoring/enforcing coding standards
- Long running features that are developed in isolation
There are many more reasons that prevent refactoring dirty code, but in this issue, I’m going to cover some practical steps you can take to start improving your codebase.
Over time, you can clean things up!
Let’s dig in:
Step 1: Establish Some Baseline Tests
In software development, establishing baseline tests is crucial to your success. Often, this is done as the plugin is developed.
However, if you’re in a situation where you need to refactor existing code and there are no tests, you need to establish some ways to test existing functionality.
What does this feature do that it needs to keep doing?
Automated Acceptance Tests
Automated acceptance tests are great in that they quickly run through a set list of scenarios for you each time you run them.
They are slower than unit or functional tests, but they are very good at following specific steps in a browser.
If you’re interested, I have an issue that covers how to set up and write your very first acceptance test.
While they can take a while to write and can be difficult to set up, they’re absolutely worth the investment.
It’s also understandable if you need something you can set up today so you can get into refactoring.
Manually Walking Through Test Scenarios
Sometimes, it’s more efficient just to write out your test steps in a spreadsheet.
Then you can walk through each of them when you’re done refactoring and verify that the functionality is complete.
I’ve set up a simple template that you can copy for your own plugin if that helps you get started quicker.
You’ll want to follow the format of:
When I [do this action]
I expect to [see some kind of response]
Here’s an example for creating a new post:
When I click “Add New”, add a title, and click “Publish”
I expect to see a notice in the admin that says, “New post successfully published”
Following that structure will help you define each expectation your users have with your plugin.
Step 2: Refactor As You Add New Features
Now that you have a baseline of tests for your plugin, you’ll want to set up tests for each new feature that you add.
Writing tests before you develop a feature is called Test Driven Development or TDD for short.
It’s a great way to make sure that you’re aligned with requirements.
It also guarantees that when you’re done—and all tests pass—you’ve actually finished the feature.
Typically, engineers will talk about TDD referring to unit tests, but you can also do this with automated or manual acceptance tests.
Now you can follow the rule of three:
1. When you’re doing something for the first time, just get it done
2. When you’re doing something similar for the second time, cringe at having to repeat but do the same thing anyway
3. When you’re doing something for the third time, start refactoring
Once you’ve completed the feature you can go back through and start refactoring without risk of breaking anything.
Your tests will tell you if you’ve broken functionality so you can correct it.
Step 3: Refactor When Fixing Bugs
One of the best times to refactor is when you are diagnosing and fixing bugs.
The first step in this process is to identify and replicate the bug.
That’s the most important piece.
Once you’ve identified the bug, you have a test case that you can write.
Once you’ve written the test case for the expected fix, you can begin fixing it and know if you’ve done that when the test passes.
In fixing bugs, you have an opportunity to refactor existing code, add testing, and make your codebase better than it was before.
To Sum It Up…
Refactoring will actually speed up your development in the future.
To ensure that you’re refactoring correctly, you’ll need to set up some baseline tests.
Investing time in writing tests for your plugin is one of the most important steps in your development and I hope I’ve inspired you to start.
