Imagine you're faced with a large JavaScript application code base that includes several specialized types of views or components. We've been tasked with adding a new drop-down to one of the payment forms within the application. We do a quick search through the code base and identify a number of different dropdown-related components:

• GenericDropdownComponent
• DropdownDataWidget
• EnhancedDropdownDataWidget
• TextDropdown
• ImageDropdown

They're confusingly named and so we'd like to get a better understanding of them before making changes or utilizing them. To do this, we can just open the source code of each component to establish how it may relate to the others (or how it does not relate).

We end up discovering that TextDropdown and ImageDropdown, for example, both appear to inherit from GenericDropdownComponent:

// TextDropdown.js
class TextDropdown extends GenericDropdownComponent {
  //...
}

// ImageDropdown.js
class ImageDropdown extends GenericDropdownComponent {

}

We also observe that both DropdownDataWidget and EnhancedDropdownDataWidget are sub-classes of TextDropdown. The naming of the enhanced drop-down widget might confuse us, and it may be something that we seek to change in the near future, but, for now, we'll need to hold our breath and just work on doing the work we've been tasked with.

By stepping through each dropdown-related source file, we can build up a solid understanding of them without having to make any changes. If the code base employs source control, then we can also blame each file to discover who originally authored it and when. This can inform us how things have changed over time. In our case, we discover the following timeline of changes:

This is incredibly helpful to us. We can see how, originally, there was only one class (named DropdownComponent), which later got changed to GenericDropdownComponent with two sub-classes, TextDropdownComponent and ImageDropdownComponent. Each of these got renamed to TextDropdown and ImageDropdown. Over time, these various changes illuminate the why of how things are at the present time. 

When looking at a code base, we often make an implicit assumption that it was created all at once and with complete foresight; however, as our timeline illustrates, the truth is far more complex. Code bases change over time in reaction to new needs. The set of people who work on a code base also changes, and each individual will inevitably have their own way of solving problems. Our acceptance of the slowly evolving nature of every code base will help us to come to terms with its imperfections.