Something that we're yet to discuss in detail is how a design can change over time. We're setting out our thoughts on what we think our application should look like, but until we write it, we won't know all of the ins-and-outs of the exact implementation.

It's important to undertake a constant re-evaluation of the work that's taking place to ensure that the quality of what's being written remains high. We've documented our design earlier, but in one key place, we've also had the realization that subpages will be very similar to each other.

Depending on how these similarities are fleshed out in code, there could be scope for refactoring and reusing in a way that isn't immediately clear when drawing up the design document. However, if the implementation does turn out to be sufficiently similar with only minor variations between each subpage, then we need to look at extracting this code into a reusable class.

Code duplication—and even worse, copying and pasting code—is a very good way of ending up with a messy code base. In the event you need to change something, tweak behavior, add a feature, or fix a bug, you'll have to do the same thing in several places, increasing the overhead of the change and increasing the chance that more mistakes will creep into your code.

Later in this chapter, we'll begin building out the code for this application. We'll also keep a close eye out for anything that looks like it might be duplicating what went before. In these cases, we'll take some time out to see whether there's functionality we can encapsulate and reuse.

Ext JS provides multiple methods to structure code—such as inheritance and mixins—and taking advantage of these methods will result in an application that is much easier to maintain and extend.