Refactoring
Changing software’s internal structure while preserving its expected observable behaviour.
What is refactoring?
Refactoring changes the internal structure of existing software while preserving its expected externally observable behaviour. Small, checkable steps help detect unintended changes. New features or a deliberately changed business rule are a separate task; they may accompany refactoring but should remain separately traceable.
In a fictional example, the same approval rule appears in several places. The team brings it together in a shared location and checks that permitted and rejected cases still behave as intended. The rule can then be changed centrally in future. Refactoring does not guarantee freedom from defects: desired behaviour and suitable checks must be clear first. Restructuring poorly understood rules merely because code is untidy can introduce new errors.
Sources
Related terms
- Technical debtA metaphor for internal software shortcomings that make later changes harder or riskier.
- Regression testA check for unwanted effects of a change on behaviour that is still required.
- Legacy systemAn existing system still in use, with technical and business dependencies accumulated over time.
- Multi-tenancyMulti-tenancy supports separate customer or group scopes in one solution. A tenant is not automatically one person or one database.
- Browser cacheThe browser cache stores suitable HTTP responses for later use. Reuse and revalidation follow the applicable rules.
- Cache invalidationCache invalidation ends reuse of a stored copy under defined rules. The source record remains a separate concern.
Articles on this topic
Software Development with ASES
Custom software, web and mobile apps