Joel's second question, "Can you make a build in one step?"

We mentioned earlier that it needs to be easy for developers and testers to build a final version of your application from the raw source code. This could be the process that compresses your CSS and JavaScript so that your users can download it more quickly. The key is that you want to be testing your work against the same final build as your users to avoid bugs creeping through.

In Ext JS 5, we can use the Sencha Cmd to create development, testing, and production builds and it can even be used to create a packaged version of your application for deployment on touch devices. In doing so, it gives a unified mechanism for your whole team to work from the same build with a single command, making Joel very happy. This also ties into his third question, "Do you make daily builds?" With the tools we've described so far, an automated build system can grab the latest and greatest code from source control, build it using the Sencha Cmd, and deploy it to a testing or beta server for evaluation.

Joel's fourth question, "Do you have an up-to-date schedule?" and his fifth question, "Do you have a spec?"

Of course, neither of these is specific to Ext JS applications, but they're tightly related to the theme of this book. We've discussed having a specification that informs your application design, but it's an up-to-date schedule that goes hand in hand. By designing your application correctly, you are dividing it into sections that can be scheduled by yourself, your team, or your management.

A single controller with its associated views and the required models could be scheduled to take a month to complete, so an app designed to have three controllers could take three months. Joel's sixth question's a little bit more specific than this though, he asks for an up-to-date schedule. This means examining your work to ensure you're meeting your schedule and adjusting accordingly. It also means learning from a slipping schedule and realizing that your design may have been flawed in some ways. A more complex view with lots of interaction will clearly take more time than a simple view, so it's not as straightforward as our "one month per controller" suggestion.

The rest of Joel's questions are more general, so we'll skip them and talk about another important facet of setting up your development process: style. Not what your developers are wearing, but the way in which they write code. There are two things to consider here, the ones related to JavaScript and the ones specific to Ext JS.

The developers of Twitter Bootstrap caused upset in 2012 by opting not to use semicolons at the end of lines of JavaScript and combining that with some slightly obtuse syntax. Refer to https://github.com/twbs/bootstrap/issues/3057.

In truth, it doesn't matter too much whether you use semicolons or not in most circumstances due to JavaScript's automatic semicolon insertion. Refer to http://ecma262-5.com/ELS5_Section_7.htm#Section_7.9.

The more important point is that whatever you do, do it consistently and make sure everyone working on your application is doing it too. Not doing this will have severe consequences for the maintainability of your application as it's developed (imagine having files with two or three different styles of commenting, string quoting, and conditional statements).

Ext JS itself has a couple of conventions that will make your life much easier if you adhere to them. When a controller requires a store, you can do it like this:

Ext.define('MyApp.controller.MyController', {
    extend: 'Ext.app.Controller',

    requires: [
        'MyApp.store.Albums'
    ],

    getAlbumsStore: function() {
        return this.getStore('Albums');
    }
});

This is equivalent to:

Ext.define('MyApp.controller.MyController', {
    extend: 'Ext.app.Controller',

    stores: ['Albums']
});

As the Store class was defined as 'MyApp.store.Albums', we can refer to it with the 'Albums' shortcut. Likewise, controllers should always have "controller" as the middle part of the class name, "model" for models, and "view" for views.

This is partially covered in the naming conventions segment of the Ext JS 5 Core Concepts guide. What isn't explicitly mentioned is the way that these shortcuts are pervasive across Ext JS and how they can make your code much clearer.