When you are beginning to consider refactoring your big legacy codebase towards a new software design, then it is not uncommon to feel helpless after estimating this to be a huge terrifying 2-5 years project. To help solve the problem of not knowing where and how to begin, we have had great success using a decision matrix to decide how each part of the legacy code should be changed in such a refactoring project. Two main factors should influence your refactoring decisions…
Read more on Refactoring Matrix…There are many different ways to teach topics of software developments. From recorded lectures to pair programming. Over the time we tried many of them with different customers and different topics. I want to provide you with an overview of what worked best for us for which topic.
Read more on Methods Of Teaching…So your code base is littered with singletons and using them? Don't worry, you can start refactoring them out of your code base class by class and introduce increased testability at every step. This strategy is very simple to implement and the propability of breaking your code is very low, especially when you are becoming more experienced with this technique.
Read more on Refactoring Singleton Usage to get Testable Code…When we join teams to coach them with refactoring their legacy code base, many of them are overwhelmed by the sheer mass of code. That typically results in the request for "some refactoring sprints" or even "a complete rewrite". Both is obviously not a solution from the business perspective - feature development and bug fixing needs to go on and the refactoring should not eat up the larges portion of time. But where and how should the team start and how should? What we call the "Advanced Boy Scout Rule" has helped many teams to come over this staleness and reach fast results while continuing to deliver business value.
Read more on Refactoring with the Advanced Boy Scout Rule…Software systems usually get more complex over time. In the beginning a variable starts out to represent something very simple with very few rules and constraints that can are enforced in a single location of the code. We will show you how you can use value object extraction to avoid spreading logic everywhere.
Read more on Extracting Value Objects…Usually the problems software needs to solve get more complex over time. As the software itself needs to model this increased complexity it is often necessary to replace entire subsystems with more efficient or flexible solutions. Instead of starting from scratch whenever this happens (often!), a better solution is to refactor the existing code and therefore reducing the risk of losing existing business rules and knowledge. A good strategy for this kind of change is called "Branch By Abstraction". While the term is certainly clumsy and overloaded, the idea itself is genious. Let's see how it works…
Read more on How You Can Successfully Ship New Code in a Legacy Codebase…Many developers want to "rewrite the whole application" and "get rid of all that sh*t". Most of them are pretty blank when I tell them that I really like working on such code bases, even if I just jumped into the code. I recently talked about that to the other Qafoo members and all of them agreed to my views. Therefore I want to explain our love of legacy code in this post.
Read more on Loving Legacy Code…
When you are refactoring in a legacy codebase, the goal is often to reduce complexity or separate concerns from classes, methods and functions that do too much work themselves. Primary candidates for refactoring are often controller classes or use-case oriented service classes (such as a UserService). Extracting new service classes is one popular refactoring to separate concerns, but without tests it is dangerous because there are many ways to break your original code – we show you how this can still be done.
Refactoring is the process of restructuring code without changing its behaviour and the technique "Extract Method" is one of the most important building blocks of refactoring. What do you need to keep in mind while doing this?
Read more on Refactoring Basics: Extract Method…When software projects grow it is considered helpful if the software follows an established structure so that every developer finds their way easily. If the used structures and patterns change per developer or even every couple of months or years it will get really hard to maintain the software. Let's discuss the reason for this and possible fixes.
Read more on Extended Definition Of Done…