Regular refactoring<\/a> helps pay attention to code properties before problems appear. It makes daily work more efficient, gives developers extra time and resources, and prevents \u201cbig refactorings\u201d in the future.<\/p>\nBenefits for Business<\/h3>\n
In a perfectly organized development process, there\u2019s no need to \u201csell\u201d refactoring to the business. In such projects, regular code improvement is at the core of the development, and bad code does not accumulate\u2014no need to \u201cexplain the benefits to the business\u201d in this case.<\/p>\n
However, there are projects where development is organized differently for various reasons. In such projects, as a rule, legacy code tends to accumulate.<\/p>\n
We may feel the need to improve the code, but we may not have enough resources to do that. A proposal to \u201ctake a week to refactor\u201d might cause a conflict of interests because, to the business, it sounds like \u201cwe\u2019ll do nothing useful for a week.\u201d These are the cases where we may need to \u201csell\u201d the ideas of the code improvement.<\/p>\n
The benefits of refactoring aren\u2019t evident to the business because they aren\u2019t immediate. We may see them in the future, but it\u2019s difficult to predict when.<\/p>\n
Usually, to sell the idea of refactoring to business, we should speak the business language, and\u00a0sell the result, not the process<\/i>. Discuss what exactly we\u2019ll get as a result of the time spent:<\/p>\n\n- We\u2019ll spend less time fixing bugs, so the number of unhappy users will drop.<\/li>\n
- We\u2019ll start implementing new features before our competitors, so they generate new users and profit.<\/li>\n
- We\u2019ll better understand the requirements and constraints, so we react to unpredicted problems faster.<\/li>\n
- We\u2019ll make onboarding easier for new developers to make significant changes sooner.<\/li>\n
- We\u2019ll decrease staff turnover because developers don\u2019t run away from good code, only from the bad one.<\/li>\n<\/ul>\n
We can use various metrics to measure code quality. It\u2019ll be much easier to determine the necessity of refactoring by relying on the numbers. For example, the costs statistics might help to incorporate regular refactoring into the development process smoothly.<\/p>\n","protected":false},"excerpt":{"rendered":"