planning javascript and ajax for larger teams

Planning JavaScript and Ajax for larger teams

Christian Heilmann

@media Ajax, London, November 2007

This is awesome!

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.

Now it is time to make it mature.

We do that in a technical manner.

The technical part will get a solution.

However, danger lurks around every corner.

How we can make JavaScript and Ajax solutions work with

larger teams?

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. 

“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.

Most of the time it is confusing because of other

assumptions.

Let’s take a look at some of them:

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

“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 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.”

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

These are all things we need to avoid.

JavaScript and Ajax are a part of the normal

development cycle.

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.

No more heroes!

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.

People will move from product to product or leave

the company.

Web products are never finished.

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

code again.

How?

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

–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

–You make JavaScript a mature technology.

What code standard?

Whatever the team agrees on and feels comfortable with.

Make sure to have a reason for your code standards.

Take time to train each new hire on them.

How can you find reasonable standards?

Conduct Code reviews

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

–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

Doesn’t that stop innovation?

Nein.

Development time is not the time to innovate or change.

Don’t listen to the

“inner hacker”.

Production code does not need to be optimized from

the start.

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 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

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

Production code is for humans.

Production code is for humans.

Live code is for machines.

In between, we have a build process.

Build process:

Build process:–Validation (Tidy, JSLint)

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)

–Tagging as “live code”

What about playtime?

Find creative outlets for team members.

Let them create reusable components identified in

code reviews.

Foster internal communication.

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.

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

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

Architect your JavaScript:

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)

–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.

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.

THANKS!

Christian Heilmann

http://wait-till-i.comchris.heilmann@gmail.com