Exploring Refactoring

Introduction

Upon reading Robert C. Martin's "Clean Code" book, I gained a newfound appreciation for Refactoring Guru's ability to convey the concept of refactoring in straightforward terms. Furthermore, Refactoring Guru's explanations of design patterns in plain language intrigued me, prompting a desire to enhance my understanding of these patterns. As a result, I opted to prioritize refining my grasp of refactoring by completing the Refactoring section before delving into the realm of design patterns.

In the coming days, my focus will be on studying Code Refactoring under the guidance of Refactoring Guru. I intend to document my learning journey on this blog, sharing both my insights and the methods I employ to acquire this knowledge. To gain a more comprehensive understanding of the topics discussed here, I encourage you to refer to https://Refactoring.Guru. This blog series serves as my initial step into the world of blogging, where I will be taking notes and sharing my learning experiences.

What is a Clean Code?

Clean code refers to well-structured, readable, and maintainable computer code that is easy to understand and modify. It is a coding philosophy and a set of principles and practices aimed at producing high-quality software. Clean code is important because it makes software development more efficient, reduces the likelihood of bugs and errors, and makes it easier for developers to collaborate on a project over time. The primary goal of refactoring is to reduce technical debt. It turns a jumble into tidy code and a basic design.

Features of Clean Code

1. Clean Code is obvious to other programmers: Clean code does not have poor variable naming, bloated classes, methods and magic numbers.

2. Clean Code doesn’t contain duplication: Duplicating code means you will have to make changes to it in every place you have the duplication.

3. Clean Code contains a minimal number of classes: Less code is fewer bugs. Code is a liability, keep it short.

4. Clean Code passes all tests, 100%.

5. Clean Code is easier and cheaper to maintain

Technical Debt

Technical debt is like postponing chores at home. Imagine you don't clean your house regularly, and over time, it becomes messier and harder to clean. Similarly, in software, when you take shortcuts or rush to finish coding without doing it properly, it creates "messy" code that's harder to maintain and can cause problems later on. You'll eventually need to spend more time cleaning up and fixing issues (paying off the debt) than if you had done it right from the start. For example, when you temporarily speed up without writing tests for new features, it will slow progress every day until you eventually pay it off by writing the tests.

Causes of Technical Debt

According to Refactoring Guru, these are the causes of technical debts:

1. Business Pressure: This is when business circumstances force you to roll out features before they are finished.

2. Lack of Understanding of Consequences of Technical Debt

3. Failing to combat the strict coherence of components.

4. Lack of Tests

5. Lack of Documentation

6. Lack of Interaction Between Team Members

7. Delayed Refactoring

8. Lack of Compliance Monitoring

9. Incompetence: This is when the developer just doesn’t know how to write decent code.

When to Refactor

1. When you add a new feature, consider taking that opportunity to clean up any existing unclean code related to that feature.

2. When you are fixing a bug.

3. During a code review, which can be an ideal moment to initiate a code refactor. This review provides an opportunity to enhance code quality before it's finalized.

Checklist for Refactoring Code

1. After refactoring your code, the improved code should be cleaner and more maintainable than the code you initially encountered.

2. Avoid introducing new functionality while refactoring. It's advisable to separate the introduction of new features and the refactoring of existing code into distinct commits or steps.

3. If there are existing tests for the code, ensure that all tests pass to confirm that the code is clean and maintains its expected behaviour.

In this article, I established what the concept of Refactoring Code is, what technical debts are and how they come to be. See you in the next article!