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

<ul><li>This is awesome! </li></ul>

<ul><li>Here we are at a
conference about JavaScript </li></ul><ul><li>(oh well, Ajax) </li></ul>

DOM Scripting Task Force

DOM Scripting Task Force

<ul><li>We’ve done it. </li></ul><ul><li>JavaScript is
cool again and people take it much more serious. </li></ul>

<ul><li>Now it is time to
make it mature. </li></ul>

<ul><li>We do that in a
technical manner. </li></ul>

<ul><li>The technical part will get
a solution. </li></ul>

<ul><li>However, danger lurks around every
corner. </li></ul>

<ul><li>How we can make JavaScript
and Ajax solutions work with larger teams? </li></ul>

<ul><li>The first step is to
stop making assumptions. </li></ul>

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

<ul><li>“Do not fiddle with other
people’s knobs unless you know what you are doing.” </li></ul>

<ul><li>JavaScript is not magic and
should not be confusing and difficult. </li></ul>

<ul><li>Most of the time it
is confusing because of other assumptions. </li></ul>

<ul><li>Let’s take a look at
some of them: </li></ul>

<ul><li>“ I don’t need to
tell people that - they know already.” </li></ul>

<ul><li>“ Surely this has been
done before - and by people better than me.” </li></ul>

<ul><li>“ This works right now.
There won’t be a need to change it.” </li></ul>

<ul><li>“ This never worked in
the past - it won’t work now.” </li></ul>

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

<ul><li>“ Hack that now and
we’ll get time later to fix it.” </li></ul>

<ul><li>These are all things we
need to avoid. </li></ul>

<ul><li>JavaScript and Ajax are a
part of the normal development cycle. </li></ul>

<ul><li>They cannot be bolted on
at the end by super-human developers. </li></ul>

<ul><li>They are as much an
accessibility and usability task as the rest of the interface is. </li></ul>

<ul><li>No more heroes! </li></ul>

<ul><li>A good developer is not
a very gifted and impressive developer. </li></ul>

<ul><li>It is a developer that
can work with others and works for the next developer to take over. </li></ul>

<ul><li>People will move from product
to product or leave the company. </li></ul>

<ul><li>Web products are never finished.
</li></ul>

<ul><li>It is time to advertise
working as if you won’t ever see the code again. </li></ul>

<ul><li>How? </li></ul>

<ul><li>Following a code standard </li></ul>

<ul><li>Following a code standard </li></ul><ul><ul><li>you
can assess the quality of code </li></ul></ul>

<ul><li>Following a code standard </li></ul><ul><ul><li>you
can assess the quality of code </li></ul></ul><ul><ul><li>easy handover from developer to developer </li></ul></ul>

<ul><li>Following a code standard </li></ul><ul><ul><li>you
can assess the quality of code </li></ul></ul><ul><ul><li>easy handover from developer to developer </li></ul></ul><ul><ul><li>reliable source control </li></ul></ul>

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

<ul><li>What code standard? </li></ul>

<ul><li>Whatever the team agrees on
and feels comfortable with. </li></ul>

<ul><li>Make sure to have a
reason for your code standards. </li></ul>

<ul><li>Take time to train each
new hire on them. </li></ul>

<ul><li>How can you find reasonable
standards? </li></ul>

<ul><li>Conduct Code reviews </li></ul>

<ul><li>Conduct Code reviews </li></ul><ul><ul><li>You find
problems and solutions. </li></ul></ul>

<ul><li>Conduct Code reviews </li></ul><ul><ul><li>You find
problems and solutions. </li></ul></ul><ul><ul><li>You assess training needs </li></ul></ul>

<ul><li>Conduct Code reviews </li></ul><ul><ul><li>You find
problems and solutions. </li></ul></ul><ul><ul><li>You assess training needs </li></ul></ul><ul><ul><li>You share the knowledge throughout the team </li></ul></ul>

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

<ul><li>Doesn’t that stop innovation? </li></ul>

<ul><li>Nein. </li></ul>

<ul><li>Development time is not the
time to innovate or change. </li></ul>

<ul><li>Don’t listen to the </li></ul><ul><li>“
inner hacker”. </li></ul>

<ul><li>Production code does not need
to be optimized from the start. </li></ul>

<ul><li>It needs to be understandable
and maintainable. </li></ul>

<ul><ul><li>use library code, even if
it appears huge (a lot of the size is a myth) </li></ul></ul>

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

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

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

<ul><ul><li>Production code is for humans.
</li></ul></ul>

<ul><ul><li>Production code is for humans.
</li></ul></ul><ul><ul><li>Live code is for machines. </li></ul></ul>

<ul><ul><li>In between, we have a
build process. </li></ul></ul>

<ul><li>Build process: </li></ul>

<ul><li>Build process: </li></ul><ul><ul><li>Validation (Tidy, JSLint)
</li></ul></ul>

<ul><li>Build process: </li></ul><ul><ul><li>Validation (Tidy, JSLint)
</li></ul></ul><ul><ul><li>Minification (JSMin, CSS minifier) </li></ul></ul>

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

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

<ul><li>What about playtime? </li></ul>

<ul><li>Find creative outlets for team
members. </li></ul>

<ul><li>Let them create reusable components
identified in code reviews. </li></ul>

<ul><li>Foster internal communication. </li></ul>

<ul><li>Lightning Talks: </li></ul><ul><ul><li>5 Minutes presentation
</li></ul></ul><ul><ul><li>5 minutes demo </li></ul></ul><ul><ul><li>5 minutes discussion </li></ul></ul><ul><li>Every Thursday </li></ul><ul><li>11.45 – 12.00 </li></ul>

<ul><li>If your company is clever,
it’ll share these finds with the world. </li></ul>

<ul><li>So how do you plan
JavaScript and Ajax for larger teams? </li></ul>

<ul><li>Get the team to talk
and agree on what works best. </li></ul>

<ul><li>Architect your JavaScript: </li></ul>

<ul><li>Architect your JavaScript: </li></ul><ul><ul><li>Modules instead
of views / pages / sections </li></ul></ul>

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

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

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

<ul><li>Involve Design and Engineering in
the process and explain the rationale of your plan. </li></ul>

<ul><li>Communication and sharing information is
better than any architectural blueprint you or I could come up with. </li></ul>

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