In safe hands

Joel's first question, "Do you use source control?"

Step one when a new developer arrives is where is your code kept? We're long past shared network drives and manually copying the code of other developers on your team, so you should be using some form of source control. This is definitely a situation in which something is better than nothing, so we won't specifically discuss the alternatives, but in my case, I'm using Git, which is created as the source control system for the Linux kernel and is now extremely popular in software development.

Each member of your team can now grab code from each other, roll back their mistakes, track changes, and find the origin of bugs. However, a source repository is not just a giant hole in which everyone's files is up. There are some that are unique to each developer (such as configuration files for an IDE), and there are some that are automatically generated by a build process or other script. With Git, we'd use a .gitignore file to exclude several items that simply create a message of your repository and commits:

# sample gitignore for extjs5
# The build directory can be recreated by developers using Sencha Cmd – it should be excluded from the repo
build/
# Changes every time a build is run
bootstrap.js
bootstrap.css

# Temporary files created when compiling .scss files
.sass-cache/

# Some team members may use Sencha architect – exclude so they keep their custom settings
.architect

# It's possible to create reusable packages using Sencha Cmd but depending on your preference you might want to exclude this directory. Packages are discussed in chapter 3.
packages/

There will be a lot more than this in a .gitignore file if your Ext JS application shares a directory with any server-side code. Most large projects will have a heavily customized .gitignore file. Moreover, not all source control systems will have a similar feature and setting it up at the start of the project will keep your application history neat and tidy.

If you build it, they will come

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.

Managing your time

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.

You can buy fashion, but you can't buy style

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.