Planning JavaScript and Ajax for larger teams

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

Slide 2: This is awesome!

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

Slide 5: DOM Scripting Task Force

Slide 6: DOM Scripting Task Force

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

Slide 8: Now it is time to make it mature.

Slide 9: We do that in a technical manner.

Slide 10: The technical part will get a solution.

Slide 11: However, danger lurks around every corner.

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

Slide 13: The first step is to stop making assumptions.

Slide 14: 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.

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

Slide 16: JavaScript is not magic and should not be confusing and difficult.

Slide 17: Most of the time it is confusing because of other assumptions.

Slide 18: Let’s take a look at some of them:

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

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

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

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

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

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

Slide 25: These are all things we need to avoid.

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

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

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

Slide 29: No more heroes!

Slide 30: A good developer is not a very gifted and impressive developer.

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

Slide 32: People will move from product to product or leave the company.

Slide 33: Web products are never finished.

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

Slide 35: How?

Slide 36: Following a code standard

Slide 37: Following a code standard – you can assess the quality of code

Slide 38: Following a code standard – you can assess the quality of code – easy handover from developer to developer

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

Slide 40: 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.

Slide 41: What code standard?

Slide 42: Whatever the team agrees on and feels comfortable with.

Slide 43: Make sure to have a reason for your code standards.

Slide 44: Take time to train each new hire on them.

Slide 45: How can you find reasonable standards?

Slide 46: Conduct Code reviews

Slide 47: Conduct Code reviews – You find problems and solutions.

Slide 48: Conduct Code reviews – You find problems and solutions. – You assess training needs

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

Slide 50: 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

Slide 51: Doesn’t that stop innovation?

Slide 52: Nein.

Slide 53: Development time is not the time to innovate or change.

Slide 54: Don’t listen to the “inner hacker”.

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

Slide 57: It needs to be understandable and maintainable.

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

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

Slide 60: – 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

Slide 61: – 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.

Slide 62: Production code is for humans.

Slide 63: Production code is for humans. Live code is for machines.

Slide 64: In between, we have a build process.

Slide 65: Build process:

Slide 66: Build process: – Validation (Tidy, JSLint)

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

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

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

Slide 70: What about playtime?

Slide 71: Find creative outlets for team members.

Slide 72: Let them create reusable components identified in code reviews.

Slide 73: Foster internal communication.

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

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

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

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

Slide 78: Architect your JavaScript:

Slide 79: Architect your JavaScript: – Modules instead of views / pages / sections

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

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

Slide 82: 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.

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

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

Slide 85: THANKS! Christian Heilmann http://wait-till-i.com chris.heilmann@gmail.com