Hire Me for Refactoring
More often then not, you will find a project with the team that struggles with the maintenance and adding new features. During the time, under pressure of deadlines, changes in the team, growth of lines of code, outdated technologies, and sometimes wrong technical decisions, the code base became hard to read, and slow to maintain.
This is the point where you often will hear that it is time to rewrite the the code from scratch. Nothing wrong with rewriting, you'll think, only if you have enough resources to do it, completely test it, find new bugs, solve them, retest it... don't do it! Old code is great collection of tested, fixed and working features. Throwing it away would mean throwing all that knowledge and hours invested.
Refactoring is much better solution. Moving a code from one place to another: grouping user interface, grouping networking functions..., removing globals, introducing namespaces, adding comments, de-duplicating same or similar functionality, generalizing it... every time make a little step that creates simpler code with equivalent behavior that will eventually be joined in a beautiful picture: code that is much easier to understand, faster to maintain and extend.
What is strange with the refactoring, is that probably any software project can use it. Still it gets postponed all over again. Even when everything points that investment in refactoring pays off sooner than any other solution you throw on the project.
How do you know if you need a refactoring:
- Look how long did it take before a new hire had a first code commit. Depending on the seniority: if more then a day for a senior developer, or more then a week for an experienced, you need to refactor.
- Your developers do not write automated tests. Asked why they will respond that the reason is complexity of the existing code.
- Fixing (even simple) bugs takes long.
- Release QA takes too long.
- Adding new feature takes too long
Finally, if you're in doubt, you probably need refactoring!