Book Image

Refactoring TypeScript

By : James Hickey
Book Image

Refactoring TypeScript

By: James Hickey

Overview of this book

Refactoring improves your code without changing its behavior. With refactoring, the best approach is to apply small targeted changes to a codebase. Instead of doing a huge sweeping change to your code, refactoring is better as a long-term and continuous enterprise. Refactoring TypeScript explains how to spot bugs and remove them from your code. You’ll start by seeing how wordy conditionals, methods, and null checks make code unhealthy and unstable. Whether it is identifying messy nested conditionals or removing unnecessary methods, this book will show various techniques to avoid these pitfalls and write code that is easier to understand, maintain, and test. By the end of the book, you’ll have learned some of the main causes of unhealthy code, tips to identify them and techniques to address them.
Table of Contents (11 chapters)

When Should I Refactor?

It's already been mentioned that refactoring is best done in smaller chunks rather than in big sweeping changes.

Again, this avoids riskier and error-prone changes. You can also ship your product to your customers in a more iterative way and get feedback from your users earlier.

Then, the question arises: When should I refactor?

The Boy Scout Rule

There's a programming principle called The Boy Scout Rule (http://www.informit.com/articles/article.aspx?p=1235624&seqNum=6) which states:

"Leave the code cleaner than you found it."

This applies whether you are fixing a bug, adding a new feature, and so on. Just do something that improves the code you are working with.

Note

It could be as simple as adjusting the name of an ambiguous variable name.

It could be reorganizing the structure of your code's files.

It could be introducing design patterns to solve specific issues.

Repetitive Work

Ever run into a situation where you need to write code that you've already written before? Maybe the same code already exists somewhere else in the system?

If you find that you've had to write the same (exact) code over and over, then you might want to consider consolidating that code into a shareable resource.

That way, you don't have to change 12 different files to fix a bug or add a new piece of logic.

Difficulty Adding Features

As we mentioned previously, sometimes, you are faced with the task of adding new features to your code. However, perhaps the existing code is making it really difficult to just add that new feature or behavior.

In these cases, refactoring can help you mold the existing code into a place where it is easy to add new behaviors!

Note

This also applies to architectural issues. However, this book will focus on more code-based issues.

In the End

In the end, refactoring should be a continuous and habitual activity that you have chosen to engage in.

Martin Fowler, on the topic of refactoring (https://www.refactoring.com/), said:

"Refactoring isn't a special task that would show up in a project plan. Done well, it's a regular part of programming activity."

You shouldn't have to ask to refactor. Just do it when it makes sense.