Refactoring

The defining condition is unchanged behaviour. If the application starts doing something new afterwards, that is development, not refactoring, and it should be estimated differently. Which leads to the key technical prerequisite: tests, or at minimum a reproducible verification scenario, must exist beforehand, otherwise there is nothing to prove behaviour stayed the same with. Typical moves are extracting a repeated fragment into a function, splitting a class that took on four responsibilities, deleting dead code, and reshaping a data schema around the scenarios that actually occur.

Selling refactoring to a client on the grounds of clean code is useless and, honestly, wrong. The conversation runs in terms of consequences: this rework exists so that adding a new delivery type stops taking two weeks instead of two days; this one so releases can go out during working hours without assembling the whole team; this one so connecting a second warehouse becomes possible at all. Refactoring needs a goal tied to specific upcoming backlog items, otherwise it becomes endless improvement for its own sake.

Two traps. The first is the big-bang refactor on a separate branch for three months: while the team rewrites, product work continues on the main branch, and the eventual merge becomes its own project with its own risks. Small steps, each of which reaches production, are far safer. The second is refactoring instead of deciding. If the architecture fundamentally does not fit the problem, cosmetically rearranging modules will not help: either change the architecture deliberately or accept that replacing the system is cheaper.

Related terms

• Technical debtTechnical debt is the accumulated gap between how a system is built and how it should have been built: every shortcut taken to hit a deadline turns into a permanent surcharge on the cost and duration of everything built afterwards.
• Legacy codeLegacy code is working code that is expensive to change: it runs on an outdated stack, has no test coverage or has lost its authors, so every edit means reconstructing the logic from the source and risks breaking something unrelated.
• CI/CDCI/CD is a pipeline that on every commit builds the project automatically, runs tests and checks, and then ships the passing build to a staging environment or to production, removing manual deployment and the human error that comes with it.
• MonolithA monolith is an application built and deployed as a single unit: all the code lives in one repository, runs in one process and works against one database, releasing as a whole, which buys simplicity at the cost of coupling.
• MicroservicesMicroservices are an architecture in which an application is split into several independent services, each with its own data and release cycle: they talk over the network through APIs, deploy separately and scale individually, but they demand mature infrastructure.

Related services

• Website support and improvementNot every project needs a rewrite. It is often cheaper to fix the speed, clear the technical SEO errors, add the missing sections and integrations, and end up with a working site without paying for a new build.
• Website development, end to endWe build sites that still hold up a year later: from a one-page CMS build to a store or a web application on React and Next.js. One team for design, code, integrations and launch.
• IT consulting and product auditThe most expensive mistakes in software happen before the first line of code: a misread problem, a stack chosen out of a contractor’s habit, and a specification that does not exist. Consulting exists to settle all of that before the development meter starts running: what to build, out of what, at what cost and in which order. The result is a document, not an opinion on a call.

Read more

• Redesigning a Site Without Losing Traffic: Stages, Risks and the SEO Migration ChecklistHalf of all redesign requests are really content, speed or offer problems. How to tell them apart, why a phased rollout beats a big bang launch, and what belongs in the migration checklist so the organic traffic survives.
• How to Choose a Tech Stack: Criteria That Outlive the HypeA stack is a five-year commitment usually made in a single call. Here is the order the decisions should be taken in, the criteria that carry real weight, working stacks for six project archetypes and what a wrong choice costs.