Diana Hille
Diana arbeitet seit 2015 für die B1 Systems GmbH. Ihr Aufgabenfeld umfasst vielfältige Themen aus dem Web- und Softwareentwicklungsbereich. Ihr Ziel ist die kontinuierliche Verbesserung der Benutzeroberfläche und der Funktionalität im Hintergrund. Daher bildet sie sich in Bereichen des DevOps und der Anwendungsentwicklung stetig weiter.
As hinted in the second part of the series, code smells can be used as an indicator for a corresponding refactoring strategy. Some of these strategies seem like common knowledge, but shouldn’t be ignored as this is often the main cause of software issues.
After establishing the advantages and disadvantages of refactoring in my previous post, the next step is to understand when and where to begin the progress. Refactoring should be best applied to the regular programming workflow, to support the programmers in their everyday work routine:
It’s a common problem in software development that – all best intentions aside – the once clean and structured code base gets more and more complicated and messy over time. There are plenty of reasons for even the most cared for code to get to this state, e.g. technical debt. At this stage the designated developer is faced with at least two options to proceed further: Recreating the code from scratch or refactoring the code base over time.
