Ruthless Refactoring: From Code You Hate to Software You Love

This session will show you how to make your code more readable, testable, and structured by doing something you should do anyway: ruthless refactoring. Developers are engineers who always prefer starting from scratch instead of working on legacy code. In this talk, we’ll see how to use some basic concepts from software architecture, applied through a series of small refactorings which can make your code not only look nice, but also be extensible and testable. We’ll go from a “spaghetti” codebase to a “fusilli” one.

Section 1: The first step in refactoring is understanding the code’s intent.

The first step in refactoring any code is to understand its intent. What is the code trying to do? What problem is it trying to solve? Once you understand the intent of the code, you can start to make changes that will improve its structure and readability.

One way to understand the intent of code is to read the comments. However, comments can be misleading or out of date. A better way to understand the intent of code is to actually read the code itself. Pay attention to the names of variables and functions, and try to understand how the code flows from one line to the next.

If you’re struggling to understand the intent of code, don’t be afraid to ask for help from other developers. Sometimes, it can be helpful to pair program with someone who is more familiar with the code.

Section 2: Refactoring isn’t about what code looks like; it’s about how well it describes the intent of the code.

Refactoring is often confused with rewriting code. However, refactoring is not about changing what the code does. It’s about changing how the code looks and flows, without changing its functionality.

The goal of refactoring is to make code more readable, maintainable, and testable. Refactoring can help you to identify and fix problems in your code, and it can also help you to make your code more efficient.

Section 3: Refactoring is a way to make your code tell a clear story.

When you refactor code, you’re essentially rewriting it in a way that makes more sense. You’re rearranging the code, renaming variables and functions, and making other changes that will make the code easier to understand.

The result of refactoring is code that tells a clear story. It’s code that is easy to read and understand, even for someone who is not familiar with the code.

Section 4: Remember, you’re not just writing code for computers: You’re writing for future developers.

When you refactor code, you’re not just making it easier for yourself to understand. You’re also making it easier for other developers to understand.

Remember, you’re not the only person who will ever work on this code. There will be other developers who come after you, and they will need to be able to understand your code.

That’s why it’s important to refactor your code in a way that makes it easy to understand. Use clear and descriptive names, and make sure that the code flows logically.

Section 5: Take time to study existing code before you start working on it.

Before you start refactoring code, take some time to study it. Understand what the code does, and how it works.

This will help you to identify any problems with the code, and it will also help you to make changes that are consistent with the existing code.

Don’t just jump into refactoring without understanding the code first. Take the time to study it, and you’ll be more likely to make changes that are successful.

Section 6: If you understand the structure, it’ll be easier to change and adapt.

One of the benefits of refactoring is that it can make code easier to change and adapt. When you refactor code, you’re essentially making it more modular. This means that the code is broken down into smaller, self-contained units, which makes it easier to change or update one unit without affecting the others.

If you understand the structure of your code, you’ll be better able to identify opportunities for refactoring. You’ll also be better able to make changes to your code without breaking it.

Section 7: The most important elements of meaningful names are clarity and specificity.

One of the simplest and most effective ways to improve the readability of your code is to use meaningful names. Meaningful names should be clear and specific. They should accurately reflect the purpose of the variable or function.

Avoid using generic names like “x” or “y.” These names don’t tell you anything about what the variable or function does. Instead, use names that are specific and descriptive. For example, instead of using “x,” you could use “productName” or “customerId.”

Section 8: There’s no single “right” way to name things.

The best way to name things is to use a consistent naming convention. This will help to ensure that your code is readable and consistent.

There are many different naming conventions that you can use. Some popular conventions include Hungarian notation, camel case, and snake case.