So, you’ve created your test and written just the right amount of code to pass that test, however, your code isn’t necessarily as tidy as it could be. This is where refactoring comes in. Refactoring is the process of restructuring your code without changing its external behaviour. It preserves the software's functionality but improves its design and structure. Once you’ve refactored your code, you can re-test it to make sure it still does the job you created it for.

There are four key things to bear in mind when it comes to refactoring. Firstly, refactor in small increments. This will help keep your team’s workload manageable. Secondly, refactor according to your organisation’s needs, not just whenever you decide you want to! Thirdly, apply a high level of communication across your team. And finally, be transparent about it and communicate openly with your stakeholders about the costs involved.

So why go to all this effort in the first place? Well, refactoring:

Makes code easier to understand and reuse
Improves code maintainability
Increases quality and robustness
Improves the design of software
And makes it easier to find bugs because the code is cleaner

There are lots of different refactorings that can help you achieve these benefits, and most modern development environments have refactoring tools built-in. These make the process much quicker and more reliable because the tools are less likely to miss anything out in comparison to a human. So, let’s take a look at some of the more common refactorings, refactor-rename, extract method, and extract constant.

You can use refactor-rename to make it clear what a variable, class or method is for. When you rename a variable, class, or method, it allows you to rename all occurrences of that variable, class or method throughout your code. This is much more efficient than manually editing your file.

You can use extract method to break your code up if it gets too long and to remove code duplication. Duplication of logic is like coding kryptonite - it introduces the risk of making a change in one place but not another, which is a huge problem when it comes to maintenance. You can also use extract method to move lines to a method that better expresses their intent. Your methods should do one provable thing, but often they’ll perform several actions whilst in development. Extracting sections of code into new methods and calling this method at the point of extraction helps to make code cleaner and more understandable. It makes unit testing much easier too.

Extract constant is also sometimes called ‘no magic numbers’. You should always try to avoid hard-coding literal values like 49 into your code. This is because another developer coming along to maintain the code probably won’t know what this number represents. There’s also the issue of maintainability – it's likely that this value will occur more than once, and you might need to revise it. You can use extract constant to choose a more meaningful name for your variables and replace the value throughout your code with the extracted constant’s name.

Before we say goodbye, there’s one more thing to cover, and that’s refactoring without tests. Code that has little or no test coverage is usually badly designed, and you should always try to have unit tests in place before you start to refactor your code, but this isn’t always possible. In some cases, you may be told not to refactor code if it has no unit tests. Under this direction, developers would have to put in the effort of creating unit tests before they can refactor the code. The effort to do this is too high, so it simply doesn’t get done and the code stays unimproved. For your code to be the best quality possible, it’s really important that you refactor it, whether you have tests in place or not.

And that's it for this video. Refactoring makes your code much easier to understand and maintain and with automatic refactoring tools such as Eclipse, we can now refactor quicker than ever before.

Refactoring with Existing Tests | SDL4 A5.1 |

About