Software Engineering


No design is perfect. During implementation, you may discover that your design needs change for a number of reasons. Most notably, a new requirement may arrive or a flaw in the current design may be discovered. Refactoring is the process by which we change the design of code without affecting its behavior. Once the design has been updated, implementation may proceed.

A great many common refactorings appear in Martin Fowler’s book, Refactoring: Improving the Design of Existing Code. The following are links to third-party summaries of the refactorings we will discuss throughout this course.

Refactorings are commonly identified as a result of code smells. The linked Wikipedia article contains a number of common code smells; it’s good to be familiar with them.

There is no single authoritative list of all refactorings or code smells, although some refactorings and smells are prominent enough to have de facto names. The above-linked refactorings and code smells are common to object-oriented languages but may not be applicable to every language. What constitutes a code smell in one language may be standard practice in another. As a software engineer, your goal is to learn the best practices in the language in which you’re working and develop an eye for bad code or design.