Scaling Up JavaScript Development
I doubt if there’s any other programming language that has such a vibrant community as JavaScript. It is already the top programming language on GitHub and new projects are popping up every minute.
This is a testimony to how easy it is to start hacking in this language. However, hackability is a double-edged sword. While JavaScript is great for explorative work and quick prototyping, it can quickly get out of control when used at a larger scale.
In the last few years I have been working mostly in teams of at least 5 JavaScript developers. JavaScript is now used to build complex applications, so such a team setup is no longer something unusual for front-end developers. This is the point when hackability of the language can be become an issue, if it’s not handled well.
It’s hard not to see that a lot of headaches we face in large projects have been already tackled by people programming in other languages. By shamelessly stealing their lessons we can dramatically improve the quality of our work. During the last months I got preoccupied with applying the following concepts to JavaScript development:
- Continuous integration with jslint or jshint
- Unit tests
- Refactoring
- Pair programming and code reviews
All these things are nothing new for anybody coming from Ruby or Java. After attending few front-end conferences, though, I had impression that these practices are not exactly bread and butter to JavaScript developers. To validate my assumption, few months ago I ran a poll on this blog. Here are the results from 77 people. Big THANK YOU to everybody who participated!
| For how long have you been writing JavaScript? | |
|---|---|
| Less than 2 years | 39.0% |
| 3-5 years | 28.6% |
| More than 5 years | 32.5% |
| jslint and jshint usage | |
| I haven’t heard about them | 9.1% |
| I have heard about them, but I haven’t used them | 22.1% |
| I use them occasionally | 36.4% |
| They are part of my normal workflow | 32.5% |
| Unit tests for JavaScript | |
| I don’t know what are unit tests | 3.9% |
| My code doesn’t need unit tests | 5.2% |
| I don’t write tests, but I would like to | 46.8% |
| I write tests occasionally | 19.5% |
| Writing unit tests is a part of my normal workflow | 24.7% |
| Continuous integration for JavaScript | |
| I don’t know what is continuous integration | 13.0% |
| I’m not using continuous integration at all in my project | 27.3% |
| Continuous integration is used in my project, but not for JavaScript code | 28.6% |
| JavaScript code in my project is tested and deployed with continuous integration | 31.2% |
| Team work and collaboration (multiple answers were possible) | |
| I don’t use any collaboration techniques | 36.4% |
| I use pair programming | 36.4% |
| I use code reviews | 51.9% |
| I use the rubber duck debugging technique with my collegaues | 22.1% |
So is the glass half full or half empty? There’s certainly an awarness of best practices. However, there are still many developers who don’t apply these practices in their work. It’s especially clear with unit testing, where there’s a large group of people who want to start writing tests, but for some reasons have not done so yet.
All of it got me motivated to promote the idea of applying lessons from other programming communities in the JavaScript world. It was the subject of my talks at Front Row and Front-Trends conferences.
From all the above practices, unit testing is in my opinion the trickiest one. Getting started with testing is not that easy and becoming good at it is a process that requires time and practice. In January I delivered a talk about unit testing and I got a lot of questions afterwards, especially from people who wanted to test their code but who didn’t exactly know how to tackle specific scenarios.
I decided to describe some of the things I learned in the article: Getting Started with JavaScript Unit Testing. I want to thank Rebecca Murphey who reviewed the draft and Morgan Roderick who introduced me to some of the tools and techniques mentioned in the text.
The beginning of the article deals with typical doubts that prevent people from writing tests, especially the notion that writing tests slows down development. The second part shows solutions to problems that you may encounter when writing tests for a real project. So if you don’t use unit tests yet, give it a spin!
Comments are closed