I like to believe I'm a quick developer. A developer capable of pushing out vast quantities of HTML and CSS in a very timely manner. At G5 (the company, not either of the two airplanes named the same), the development team has managed to cut our average build time roughly in half over the past two years.
Today, I want to outline one simple technique that has enabled us to be vastly more efficient. I call it human test driven development. It's kind of like real test driven development, except it's easy to do on the front end (sorry, Selenium, you don't count as easy).
At it's heart, test driven development is writing a to-do list. Granted, it's writing a very complicated, completely automated to-do list. A to-do list capable of telling you when you haven't done what you set out to do. Kind of like a shopping list that would let you know you forgot the milk as you're heading to the checkout line.
Before writing a single line of code, you write your tests. Actually, your tests are code, so you begin writing your code by writing your tests. Each test essentially says two things:
Your test suite can then be run again and again, every time the code is modified. A truly beautiful TDD app with 100% test coverage tells you something is messed up as you write your new code. This means very complex apps can essentially check themselves from the inside out to make sure no new changes will break other bits of code.
Wouldn't it be great if HTML and CSS were easily testable? To know that editing one line of CSS will break a module in a hidden corner of the site. The short answer is that there are ways of making testable front end apps. But they all seem quite complex, and even hardcore TDD practitioners sometimes argue that testing the view is not worthwhile unless you have a single, very large app or site (Amazon would be a good candidate).
If you develop smaller sites or a vast majority of sites, full bore TDD of views probably isn't economical.
Let's look at the first half of the TDD process. A coder starts by outlining the tests. This is easy, and we can do this pretty simply. Here is my basic list of things that need to be done when coding a standard website.
Our test driven developer writes the tests first, before writing the real methods and functions of the program. In HTML, we can stub out each section with a comment. That means we can create our entire HTML structure in comments before writing the code.
Once we have the comments written (our tests), we go through and flesh each one out with the semantic HTML.
The exact same process is done with the CSS. Comment the CSS document, moving from the highest level to the smallest.
This technique helps focus the mind. We can easily sketch out the document semantically with comments. This should be a relatively simple process, since we don't have to worry about the real HTML, we just say: this goes before that in the code and these are the elements and modules I'll need to create.
Then, when writing the HTML and CSS we have the scope tightly defined. We can think: it doesn't matter what the rest of the project is, my task right now is to write the HTML for the header and that is all. Then we move on to the next task, which might be writing the structure of the content area or maybe adding CSS styles to the header.
It took me about three projects to get used to this tingly scoped, nested to-do list process that I've been calling human test driven development. Once I got to the fourth project, I noticed a vast increase in speed, and now use this process on all web projects I do.
Really, the process is nothing more than breaking a large project down into a series of smaller problems, which is something that is taught during sixth grade math. It's not a new idea by any means. Framing it within the constraints of test driven development helps me wrap my head around the technique and how it applies to front end web development.
I hope it can help you as well.
Thoughts? Hit me up on Twitter @honzie.