Reliable JavaScript. Lawrence Spencer

information describing how to verify your account and complete the joining process.

      NOTE You can read messages in the forums without joining P2P, but in order to post your own messages, you must join.

      Once you join, you can post new messages and respond to messages other users post. You can read messages at any time on the web. If you would like to have new messages from a particular forum e-mailed to you, click the Subscribe to This Forum icon by the forum name in the forum listing.

      For more information about how to use the Wrox P2P, be sure to read the P2P FAQs for answers to questions about how the forum software works, as well as many common questions specific to P2P and Wrox books. To read the FAQs, click the FAQ link on any P2P page.

      PART I

      Laying a Solid Foundation

      CHAPTER 1

      Practicing Skillful Software Engineering

      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.

      WRITING CODE THAT STARTS CORRECT

      What Johann Sebastian Bach said about playing a keyboard instrument applies equally to programming a computer: There’s nothing remarkable about it. All one has to do is hit the right keys at the right time and the instrument plays itself.

      This section is about hitting the right keys at the right time. As you might guess, there’s more to it than the uninitiated might think.

      But first, a story.

      Mastering the Features of JavaScript

      Have you ever seen someone get his head chopped off on a squash court? One of us nearly did. It was during an introductory college course in the sport, but the episode had a lot to teach about writing reliable JavaScript.

      In case you’re not familiar with the game, it’s played in a court that is like a large room. Two players alternate hitting a ball with their rackets toward the back wall, which they both face. In the most basic scenario, you hit the ball at the wall; it bounces off and then bounces off the floor toward your opponent, who is standing next to you. Then he smashes it toward the back wall for you to try to hit.

      Anyway, it was the first day of the course. The instructor was standing to the student’s left and a little behind him, and the rest of us were watching through the glass front wall. The instructor directed the student to hit the ball toward the back wall.

      The student, who was a tennis player, hit a forehand as he would in tennis, stroking from low to high, with a high follow-through that wrapped around his body. That is how you hit with topspin in tennis. It’s also how you chop off the head of whoever happens to be standing to your left and a little behind you.

      Fortunately, the instructor knew this would happen and had positioned his racket in front of his face to defend himself.

      The student’s racket crashed against the instructor’s, making a lot of noise and causing the student some embarrassment, but no harm was done.

      The instructor pointed out that in tennis, you generally hit with topspin so the ball dives down and bounces up with a kick toward your opponent. However, that same stroke in squash does the opposite. If you hit with topspin, the squash ball will kick up off the wall, making an easy, looping arc, and then bounce in a lazy manner off the floor, whence your opponent will crush it. In squash, you want to hit with backspin. The ball will then kick down off the wall, and kick off the floor toward your opponent with increased velocity.

      The normal stroke in squash, then, is a chopping, downward motion to impart backspin – just the opposite of the typical stroke in tennis.

      Even though the two sports have basic features in common (two players, rackets, and a ball) as well as common demands (good hand-eye coordination, good anticipation and movement on your feet), you won’t play squash well if you try to hit the ball as you would in tennis.

      In the same way, JavaScript makes its particular demands on the programmer. If you come to large-scale JavaScript development with primary experience in another language, you will do well to attune yourself to the differences in technique.

      The differences are at both the small scale of syntax and the large scale of architecture and engineering.

      Throughout this book, you will encounter JavaScript’s unique syntactic delights. Many of them are summarized in Chapter 25. This chapter looks at the larger issues of how JavaScript’s peculiarities make certain engineering techniques possible.

      By employing these techniques, you will write JavaScript with kick. Your game will improve. You will “win” more often because you will be working with the language instead of contrary to it.

       Case Study: D3.js

      Mike Bostock’s JavaScript masterpiece, D3.js, is a perfect example.

D3 stands for Data-Driven Documents, so called because it lets you create beautiful SVG graphics from data. For example, Figure 1.1 is a D3 diagram that shows class dependencies in a software system (from http://bl.ocks.org/mbostock/4341134).