Читать книгу Reliable JavaScript - Lawrence Spencer - Страница 19

WHAT’S IN THIS CHAPTER?

● Writing code that starts correct

● Writing code that stays correct

WROX.COM CODE DOWNLOADS FOR THIS CHAPTER

You can find the wrox.com code downloads for this chapter at www.wrox.com/go/reliablejavascript on the Download Code tab. The code is in the Chapter 1 download and organized in directories according to this chapter’s topics, with each directory holding one sample. You can run a sample by copying its directory to your hard drive and double-clicking on the index.html file.

Few professions are more humbling than computer programming. If we did things right the first time, we could accomplish a day’s work in about 20 minutes. That’s how long it would take to type the debugged lines of code most of us pump out in a day.

We spend the rest of our time correcting our mistakes as brought to our attention by the compiler, the QA staff, our bosses, and our customers.

As anyone who has worked on a “mature” system knows, we also waste a lot of time refactoring (or wishing it were possible to refactor) code that has grown brittle and unmaintainable over the years, thanks to poor design decisions by our fellow programmers or even ourselves.

Yet somehow, we continue to think we’re pretty smart, and that only makes things worse. All our lives, we’ve been the ones who can figure stuff out. We love puzzles and problems. We’re the guys (most of us are guys, and that probably also makes things worse) who don’t like to ask for directions and don’t like to read instructions.

Plunk us down in the middle of a problem, and we’re optimistic that we can find the way out. On our own.

This chapter brings good news. Software developers are smart, and some of them have developed techniques that will help us create a lot more than 20 minutes’ worth of code in a day, and with vastly increased aesthetic satisfaction.

These techniques are not new. Every idea in this chapter is at least a decade old. However, as we have interviewed dozens of candidates for developer positions for our team, from both the United States and abroad, very few have heard of the principles behind the SOLID acronym (let alone the acronym itself). They may have heard of DRY code, but they do not appreciate its absolutely central role in good software development. Misconceptions about unit-testing abound, with many developers unaware of the benefits of letting tests drive the development process.

When you have mastered these ideas, you will be among the elite. Most developers know about object-oriented programming. Only a few also know about dependency inversion and the Liskov Substitution Principle. Fewer still have mastered test-driven development.