There must be something that can be done to prevent this decay, right? The answer is probably predictable, given the topic of this book. But let me answer with a quote from Michael Feathers on the definition of legacy code:

As we discussed in earlier chapters, tests allow you to refactor. The ability to change the structure of the code is precisely what can prevent the rot and decay that is legacy code.

While tests can allow you to prevent legacy code from forming, be aware that they themselves do not prevent the legacy problem. It takes the dedication of every person on the team understanding that building cruft into a system is a negative behavior and must be avoided. If you feel yourself working against the design of the system, then it is your responsibility to refactor the application into a design that works for today's needs and is flexible enough for tomorrow's needs.

Making a system flexible is not as hard as you might think. Following the SOLID principles (discussed in Chapter 7,  Setting up a JavaScript Environment) will help to produce a maintainable and flexible system. Even with a flexible system, it takes discipline and determination to maintain a standard of recognizing and fixing friction in the application.

The process of finding that friction could be considered PDD (Pain Driven Development). This concept means to do the simplest thing to solve your existing problem and actively recognize any friction that arises during future modifications to the application.

PDD can be applied to any system, including the application, your team, and your personal life. Following this strategy, you will become obsessed with removing friction in all things, and can get a little carried away. So, it is important to keep in mind that you might be the only one looking for this friction, and the rest of the world might be ignorant to the pain they are causing themselves. Also, keep in mind that people do not, generally, enjoy having their ignorance pointed out.