I’m not sure what kind of asset you could buy to this end. I can recommend some subjects and you can easily find very popular reading material in each of those topics.
Code Qualities
There are objective and subjective properties of code that make it easier to change going forward. These properties are collectively referred to as code qualities. A mountain of material can be found on this topic and it is a basic analytical framework that underpins and drives object-oriented programming and design, design patterns/pattern-oriented thinking, and even test-driven development.
Design Patterns
Going back as far as Christopher Alexander writing about architecture (real architecture, not software architecture), people have been moving how we think about design from bottom-up synthesis (taking little concepts and assembling them into something useful) to context-driven distinction (taking big concepts and dividing them up into smaller pieces that support the whole). At its core, Design Patterns is about making this mental shift.
There are recurring problems in any kind of design-space, whether it is architecture, software, logo development, or carpentry. Collections of wisdom around how to wrangle the forces intrinsic to those problems accumulate until we have enough data to form what we call a pattern.
For instance, a recurring problem is that you have a family of interchangeable algorithms and each variant has something in common but also has some parts that are different. That’s the problem addressed by the Template Method pattern.
The patterns, themselves, aren’t really that important. They are just starting points and a mechanism for high-bandwidth conversation between professionals in the same or similar lines of work. The mental shift to attend to the primary forces in software development…that’s the brass ring.
Briefly, you want to design stuff from the outside-in rather than inside-out, find concepts that vary in your design and encapsulate the variation (hide that they vary from anything that need not know), and favor delegation between objects over inheritance wherever you can (meaning, use inheritance to categorize alternatives rather than to specialize from a generalization).
Test-Driven Development
Test-Driven Development (TDD) is, again, some useful advice that really becomes powerful when it triggers a mental shift. The shift here is in what you consider to be the primary or authoritative artifacts in your code base. A lot of people think of their production (or, in this case, game) code as the “real” code and everything else is kind of a second-class citizen.
Once you’ve truly embraced TDD, you won’t feel that way. Passing, meaningful tests (ones that define a single behavior and pass or fail based only on the presence or absence of that behavior) become your goal. If there’s a second-class citizen in your code base, it’s your production code. That’s just this derivative stuff you have to do to get the next test to pass. Of course, you will never truly stop valuing your production code but, given enough time, you will probably start to consider it the lesser of two equals.
People often confuse TDD with test-first. Test-first is a technique we frequently employ in TDD but it is not TDD. TDD is a lot more than that.
One of the more important takeaways from adopting and embracing TDD is that your tests inform your design decisions. It is especially good at telling you when there is something wrong with your design. Understanding design patterns can help you figure out how to make it right.
Once you’ve made the decision to change your design, you want to do so safely and, it turns out that good test coverage also helps you do that, too.
Refactoring
The other big spoke on the wheel of being a developer is refactoring. It’s a word that gets bandied about a lot but it actually has a very specific meaning.
Refactoring is a controlled, verified, behavior-preserving change to design. If you are changing behavior, you are not refactoring. That doesn’t mean you’re doing the wrong thing. It just means what you are doing is not refactoring.
The nice thing about refactoring is that it is very safe. It is done in very tiny increments and each increment is nearly-instantaneously verified to be behavior-preserving. Because each step is so safe and you will so quickly get feedback when you’ve made a misstep, you can go fast. The same way that having brakes on your car gives you the confidence to drive at higher speeds than you would consider if you had to Fred Flintstone your way to a stop every time.
A good rule of thump is that each change (unbroken interval of time during which your tests are not compiling and passing) should only either modify your tests or your production code but never both.
Tying It All Together
Google will give you reams of information on each of those topics. Heck, they are so prolific, even Yahoo! might.
When you’ve studied and internalized all those things, you will be able to use TDD to get feedback about what’s wrong with your design or your behavior, use design patterns to pick the right designs, use refactoring to safely move from one design to another, and attend to code qualities throughout.