liveBook · Manning

Refactoring

As explained in Think Like a Software Engineering Manager

Refactoring is the restructuring of software code to improve its internal quality without changing its externally intended behavior.

Refactoring restructures software code to improve its internal quality without changing its intended external behavior. It is one way to address technical debt created by expedient design or implementation decisions. section 12.2.3

A deadline shortcut

A team may accept duplicate code or an incomplete implementation to meet an urgent delivery date. Later, refactoring can revisit the affected architecture while preserving the feature’s intended behavior. section 12.2.3

Use these questions to identify refactoring opportunities and reduce the resulting debt:

  • Can duplicate code be removed? section 12.2.3
  • Can the code become more modular and extensible? section 12.2.3
  • What design blind spots, review gaps, or negative effects elsewhere might the change create? section 12.2.3

How Think Like a Software Engineering Manager covers it

How deep it goes
Defines refactoring through technical-debt management and supplies review questions, but stops short of implementation techniques.
Examples
Uses deadline-driven shortcuts, duplicate code, incomplete features, design reviews, and future architectural revision as examples.
What you can do after
Evaluate technical debt by questioning duplication, modularity, review quality, testing, documentation, and system-wide effects.
How it connects
Connects refactoring with technical debt, code quality, architecture, modularity, code review, test coverage, and documentation.

Also explained in

Compare how 22 books explain refactoring →

Related concepts

This explainer was generated by Manning's knowledge graph from the text of Think Like a Software Engineering Manager. The section links point to the parts of the book it draws on.