A software delivery team (business, development, infrastructure, and QE, if available) should be aligned on why we refactor code. We refactor code to save our employer time and money in three ways:
- Decreasing the time necessary to bring features to our customers.
- Minimize the probability of production issues.
- Decrease the recovery time in the rare occasion that an issue occurs.
For refactoring to be a pleasant experience for everyone, it must be an acceptable and encouraged behavior within the delivery team. Business understands that it might take longer now, but it will save us time as we add more features or when the inevitable happens and requirements change.
Development team members embrace collective code ownership. Team members hold each other accountable, and help one another to align the solution domain to the problem domain. Testing becomes a first-class citizen in the codebase. High-quality tests make refactoring a safe activity.
Any delivery team member should be able to run tests locally, not only unit tests, but also integration tests and BDD/QE tests locally. Shortening the feedback loop makes for a safer refactoring experience and makes for a better development experience overall.
APIs, database tables, events, and messages are hard to change and refactor. The team needs to account for how to refactor each. Techniques such as migrations for databases and versioning for APIs, events, and messages are vital in making it cheap to refactor. Yes, a team might deliver an MVP without any of these tools, but once we start to make changes and add features, we need such tooling in place.
Refactoring is a high-yield investment. By aligning on why we refactor and how we make it a safe and fast activity, we decrease the cost and risk of our investment.
Illustration by OpenAI’s DALL-E, generated on 2024–01–01
Comments powered by Disqus.