planning javascript and ajax for larger teams
DESCRIPTION
My talk at the @media Ajax conference in London in November 2007 about the non-technical steps you can take to make JavaScript and Ajax work for larger teams.TRANSCRIPT
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.
