In the fast-paced world of software development, maintaining code health while delivering new features is a constant challenge. One strategy that has emerged as a crucial practice is refactoring. However, the traditional approach to refactoring can often clash with the demands of project timelines and stakeholder expectations.
In this post, we’ll explore how sustainable refactoring techniques can help strike a balance between code health and feature delivery.
[Read More]Previously, we talked about potential issues switch-case can cause, and what
to do when the type affects only data, or behavior, too.
Now that we are switch-case ninjas, we can go even further and see how to
tackle when the type code and the behavior change dynamically at runtime.
Previously in the series, we saw that AI tools have limitations. We also discussed maximizing our productivity by using them to write code - without shooting ourselves in our legs.
In this post, we’ll cover one more piece of the puzzle: how they can (or can’t) help us to refactor.
[Read More]We’ve previously dived into the complexities and maintenance challenges of
switch-case and saw a refactoring technique for simple scenarios.
Today, we’ll raise the bar a bit and focus on situations when our type code affects behavior. We’ll use pets to demonstrate the concepts.
[Read More]In the previous part, we had an overview of why switch-case could be hard to
maintain. This part will focus on the simplest scenario: when type-code only
affects data, not behavior. We’ll do this by modeling a pizzeria.
In a nutshell: switch-case makes code harder to maintain. We’ll understand
the reasons to eliminate it and see when its usage is justified.