Planning JavaScript and Ajax for larger teams Christian Heilmann @media Ajax, London, November 2007

This is awesome!

This is awesome!

Here we are at a conference about JavaScript (oh well, Ajax)

Here we are at a conference about JavaScript

(oh well, Ajax)

DOM Scripting Task Force

DOM Scripting Task Force

We’ve done it. JavaScript is cool again and people take it much more serious.

We’ve done it.

JavaScript is cool again and people take it much more serious.

Now it is time to make it mature.

Now it is time to make it mature.

We do that in a technical manner.

We do that in a technical manner.

The technical part will get a solution.

The technical part will get a solution.

However, danger lurks around every corner.

However, danger lurks around every corner.

How we can make JavaScript and Ajax solutions work with larger teams?

How we can make JavaScript and Ajax solutions work with larger teams?

The first step is to stop making assumptions.

The first step is to stop making assumptions.

Achtung alles Lookenpeepers! Dies Machine is nicht fur gefingerpoken und mittengraben. Is easy schnappen der springenwerk, blowenfusen und poppencorken mit spitzensparken. Is nicht fur gewerken by das dummkopfen. Das rubbernecken sightseeren keepen Cottenpickenen hands in das pockets - relaxen und Watch Das Blinken Lights.

Dies Machine is nicht fur gefingerpoken und mittengraben.

Is easy schnappen der springenwerk, blowenfusen und poppencorken mit spitzensparken.

Is nicht fur gewerken by das dummkopfen.

Das rubbernecken sightseeren keepen Cottenpickenen hands in das pockets - relaxen und Watch Das Blinken Lights.

“Do not fiddle with other people’s knobs unless you know what you are doing.”

“Do not fiddle with other people’s knobs unless you know what you are doing.”

JavaScript is not magic and should not be confusing and difficult.

JavaScript is not magic and should not be confusing and difficult.

Most of the time it is confusing because of other assumptions.

Most of the time it is confusing because of other assumptions.

Let’s take a look at some of them:

Let’s take a look at some of them:

“ I don’t need to tell people that - they know already.”

“ I don’t need to tell people that - they know already.”

“ Surely this has been done before - and by people better than me.”

“ Surely this has been done before - and by people better than me.”

“ This works right now. There won’t be a need to change it.”

“ This works right now. There won’t be a need to change it.”

“ This never worked in the past - it won’t work now.”

“ This never worked in the past - it won’t work now.”

“ This is a minor issue only for this instance – there’s no need to file a bug.”

“ This is a minor issue only for this instance – there’s no need to file a bug.”

“ Hack that now and we’ll get time later to fix it.”

“ Hack that now and we’ll get time later to fix it.”

These are all things we need to avoid.

These are all things we need to avoid.

JavaScript and Ajax are a part of the normal development cycle.

JavaScript and Ajax are a part of the normal development cycle.

They cannot be bolted on at the end by super-human developers.

They cannot be bolted on at the end by super-human developers.

They are as much an accessibility and usability task as the rest of the interface is.

They are as much an accessibility and usability task as the rest of the interface is.

No more heroes!

No more heroes!

A good developer is not a very gifted and impressive developer.

A good developer is not a very gifted and impressive developer.

It is a developer that can work with others and works for the next developer to take over.

It is a developer that can work with others and works for the next developer to take over.

People will move from product to product or leave the company.

People will move from product to product or leave the company.

Web products are never finished.

Web products are never finished.

It is time to advertise working as if you won’t ever see the code again.

It is time to advertise working as if you won’t ever see the code again.

How?

How?

Following a code standard

Following a code standard

Following a code standard you can assess the quality of code

Following a code standard

you can assess the quality of code

Following a code standard you can assess the quality of code easy handover from developer to developer

Following a code standard

you can assess the quality of code

easy handover from developer to developer

Following a code standard you can assess the quality of code easy handover from developer to developer reliable source control

Following a code standard

you can assess the quality of code

easy handover from developer to developer

reliable source control

Following a code standard you can assess the quality of code easy handover from developer to developer reliable source control You make JavaScript a mature technology.

Following a code standard

you can assess the quality of code

easy handover from developer to developer

reliable source control

You make JavaScript a mature technology.

What code standard?

What code standard?

Whatever the team agrees on and feels comfortable with.

Whatever the team agrees on and feels comfortable with.

Make sure to have a reason for your code standards.

Make sure to have a reason for your code standards.

Take time to train each new hire on them.

Take time to train each new hire on them.

How can you find reasonable standards?

How can you find reasonable standards?

Conduct Code reviews

Conduct Code reviews

Conduct Code reviews You find problems and solutions.

Conduct Code reviews

You find problems and solutions.

Conduct Code reviews You find problems and solutions. You assess training needs

Conduct Code reviews

You find problems and solutions.

You assess training needs

Conduct Code reviews You find problems and solutions. You assess training needs You share the knowledge throughout the team

Conduct Code reviews

You find problems and solutions.

You assess training needs

You share the knowledge throughout the team

Conduct Code reviews You find problems and solutions. You assess training needs You share the knowledge throughout the team You can identify code that should be a reusable component

Conduct Code reviews

You find problems and solutions.

You assess training needs

You share the knowledge throughout the team

You can identify code that should be a reusable component

Doesn’t that stop innovation?

Doesn’t that stop innovation?

Nein.

Nein.

Development time is not the time to innovate or change.

Development time is not the time to innovate or change.

Don’t listen to the “ inner hacker”.

Don’t listen to the

“ inner hacker”.

Production code does not need to be optimized from the start.

Production code does not need to be optimized from the start.

It needs to be understandable and maintainable.

It needs to be understandable and maintainable.

use library code, even if it appears huge (a lot of the size is a myth)

use library code, even if it appears huge (a lot of the size is a myth)

use library code, even if it appears huge (a lot of the size is a myth) Use comments to explain what is going on

use library code, even if it appears huge (a lot of the size is a myth)

Use comments to explain what is going on

use library code, even if it appears huge (a lot of the size is a myth) Use comments to explain what is going on Use explanatory variable and method names

use library code, even if it appears huge (a lot of the size is a myth)

Use comments to explain what is going on

Use explanatory variable and method names

use library code, even if it appears huge (a lot of the size is a myth) Use comments to explain what is going on Use explanatory variable and method names Don’t reinvent the wheel even if you consider yours superior.

use library code, even if it appears huge (a lot of the size is a myth)

Use comments to explain what is going on

Use explanatory variable and method names

Don’t reinvent the wheel even if you consider yours superior.

Production code is for humans.

Production code is for humans.

Production code is for humans. Live code is for machines.

Production code is for humans.

Live code is for machines.

In between, we have a build process.

In between, we have a build process.

Build process:

Build process:

Build process: Validation (Tidy, JSLint)

Build process:

Validation (Tidy, JSLint)

Build process: Validation (Tidy, JSLint) Minification (JSMin, CSS minifier)

Build process:

Validation (Tidy, JSLint)

Minification (JSMin, CSS minifier)

Build process: Validation (Tidy, JSLint) Minification (JSMin, CSS minifier) Consolidation (one CSS and one JS instead of dozens)

Build process:

Validation (Tidy, JSLint)

Minification (JSMin, CSS minifier)

Consolidation (one CSS and one JS instead of dozens)

Build process: Validation (Tidy, JSLint) Minification (JSMin, CSS minifier) Consolidation (one CSS and one JS instead of dozens) Tagging as “live code”

Build process:

Validation (Tidy, JSLint)

Minification (JSMin, CSS minifier)

Consolidation (one CSS and one JS instead of dozens)

Tagging as “live code”

What about playtime?

What about playtime?

Find creative outlets for team members.

Find creative outlets for team members.

Let them create reusable components identified in code reviews.

Let them create reusable components identified in code reviews.

Foster internal communication.

Foster internal communication.

Lightning Talks: 5 Minutes presentation 5 minutes demo 5 minutes discussion Every Thursday 11.45 – 12.00

Lightning Talks:

5 Minutes presentation

5 minutes demo

5 minutes discussion

Every Thursday

11.45 – 12.00

If your company is clever, it’ll share these finds with the world.

If your company is clever, it’ll share these finds with the world.

So how do you plan JavaScript and Ajax for larger teams?

So how do you plan JavaScript and Ajax for larger teams?

Get the team to talk and agree on what works best.

Get the team to talk and agree on what works best.

Architect your JavaScript:

Architect your JavaScript:

Architect your JavaScript: Modules instead of views / pages / sections

Architect your JavaScript:

Modules instead of views / pages / sections

Architect your JavaScript: Modules instead of views / pages / sections Skins for each module (JS,non-JS state)

Architect your JavaScript:

Modules instead of views / pages / sections

Skins for each module (JS,non-JS state)

Architect your JavaScript: Modules instead of views / pages / sections Skins for each module (JS,non-JS state) Configuration options for each module.

Architect your JavaScript:

Modules instead of views / pages / sections

Skins for each module (JS,non-JS state)

Configuration options for each module.

Architect your JavaScript: Modules instead of views / pages / sections Skins for each module (JS,non-JS state) Configuration options for each module. Events for module and application changes.

Architect your JavaScript:

Modules instead of views / pages / sections

Skins for each module (JS,non-JS state)

Configuration options for each module.

Events for module and application changes.

Involve Design and Engineering in the process and explain the rationale of your plan.

Involve Design and Engineering in the process and explain the rationale of your plan.

Communication and sharing information is better than any architectural blueprint you or I could come up with.

Communication and sharing information is better than any architectural blueprint you or I could come up with.

THANKS! Christian Heilmann http://wait-till-i.com [email_address]

THANKS!

Christian

Heilmann

http://wait-till-i.com

[email_address]