Everyone who has worked in our industry has surely encountered a project, code which caused concern. The parts of such a system are highly interconnected, and for some reason, changing the code of one function leads to the complete failure of the system. another. When adding a new module, one has to limit changes to a minimum and hold their breath, waiting for the consequences. It’s like playing Jenga with the floors of a skyscraper – it inevitably leads to disaster.
Making changes is so nerve-wracking only because the system is sick. It needs treatment, otherwise its condition will only worsen. You know the flaws in the system, but you are afraid to take decisive action. An experienced surgeon knows that it is necessary to make incisions to perform the surgery, but he also knows that the incisions are temporary and will heal afterward. The result of the surgery justifies the suffering endured, and the patient’s condition should improve compared to before the surgical intervention.
Don’t be afraid of your code. Who cares if the code doesn’t work while you’re working on it? It is precisely the fear of change that has brought your project to its current sorry state. The time spent on refactoring will pay off many times over during the lifecycle of your project. Moreover, reworking an unhealthy system will make all team members specialists in its structure. Such experience should be valued, not complained about. But working on a system that constantly causes nausea is not the best choice in life.
Override the internal interfaces. Restructure the modules. Reorganize the code obtained through copy-pasting. Simplify the architecture by reducing the number of dependencies. The complexity of the code can be significantly reduced by eliminating pathological cases, which often arise from poorly organized interactions between parts of the system. Slowly transition from the old structure to the new one, keeping testing in mind throughout the process. Attempting to refactor “in one go” can cause so many problems that doubts may arise about the feasibility of the overhaul altogether.
Become a surgeon, boldly removing affected tissues in the name of healing. Such an approach is contagious and will inspire your colleagues to carry out the long-overdue cleanup in other projects. Keep a list of “hygienic” tasks that, in the team’s opinion, would benefit the project. Convince the management that, despite the lack of visible results, such work reduces costs and speeds up the release of new versions. Constantly show concern for the overall “health” of the code.