Planning JavaScript and Ajax for larger teams
Download as PPT, PDF16 likes7,610 views
The document discusses strategies for effectively planning JavaScript and AJAX development in larger teams, emphasizing the importance of collaboration and adherence to code standards. It highlights the dangers of assumptions in coding practices and outlines the necessity of code reviews to ensure quality, maintainability, and easy handovers. Furthermore, it encourages a modular architecture approach and internal communication to foster creativity and innovation among team members.
![THANKS! Christian Heilmann http://wait-till-i.com [email_address]](https://image.slidesharecdn.com/planning-javascript-and-ajax-for-larger-teams-1195639156647064-5/85/Planning-JavaScript-and-Ajax-for-larger-teams-85-320.jpg)
Planning JavaScript and Ajax for larger teams
- 1. Planning JavaScript and Ajax for larger teams Christian Heilmann @media Ajax, London, November 2007
- 3. Here we are at a conference about JavaScript (oh well, Ajax)
- 5. DOM Scripting Task Force
- 6. DOM Scripting Task Force
- 7. We’ve done it. JavaScript is cool again and people take it much more serious.
- 8. Now it is time to make it mature.
- 9. We do that in a technical manner.
- 10. The technical part will get a solution.
- 11. However, danger lurks around every corner.
- 12. How we can make JavaScript and Ajax solutions work with larger teams?
- 13. The first step is to stop making assumptions.
- 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.
- 15. “Do not fiddle with other people’s knobs unless you know what you are doing.”
- 16. JavaScript is not magic and should not be confusing and difficult.
- 17. Most of the time it is confusing because of other assumptions.
- 18. Let’s take a look at some of them:
- 19. “ I don’t need to tell people that - they know already.”
- 20. “ Surely this has been done before - and by people better than me.”
- 21. “ This works right now. There won’t be a need to change it.”
- 22. “ This never worked in the past - it won’t work now.”
- 23. “ This is a minor issue only for this instance – there’s no need to file a bug.”
- 24. “ Hack that now and we’ll get time later to fix it.”
- 25. These are all things we need to avoid.
- 26. JavaScript and Ajax are a part of the normal development cycle.
- 27. They cannot be bolted on at the end by super-human developers.
- 28. They are as much an accessibility and usability task as the rest of the interface is.
- 29. No more heroes!
- 30. A good developer is not a very gifted and impressive developer.
- 31. It is a developer that can work with others and works for the next developer to take over.
- 32. People will move from product to product or leave the company.
- 33. Web products are never finished.
- 34. It is time to advertise working as if you won’t ever see the code again.
- 35. How?
- 36. Following a code standard
- 37. Following a code standard you can assess the quality of code
- 38. Following a code standard you can assess the quality of code easy handover from developer to developer
- 39. Following a code standard you can assess the quality of code easy handover from developer to developer reliable source control
- 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.
- 42. Whatever the team agrees on and feels comfortable with.
- 43. Make sure to have a reason for your code standards.
- 44. Take time to train each new hire on them.
- 45. How can you find reasonable standards?
- 47. Conduct Code reviews You find problems and solutions.
- 48. Conduct Code reviews You find problems and solutions. You assess training needs
- 49. Conduct Code reviews You find problems and solutions. You assess training needs You share the knowledge throughout the team
- 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
- 51. Doesn’t that stop innovation?
- 52. Nein.
- 53. Development time is not the time to innovate or change.
- 54. Don’t listen to the “ inner hacker”.
- 56. Production code does not need to be optimized from the start.
- 57. It needs to be understandable and maintainable.
- 58. use library code, even if it appears huge (a lot of the size is a myth)
- 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
- 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
- 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.
- 62. Production code is for humans.
- 63. Production code is for humans. Live code is for machines.
- 64. In between, we have a build process.
- 65. Build process:
- 66. Build process: Validation (Tidy, JSLint)
- 67. Build process: Validation (Tidy, JSLint) Minification (JSMin, CSS minifier)
- 68. Build process: Validation (Tidy, JSLint) Minification (JSMin, CSS minifier) Consolidation (one CSS and one JS instead of dozens)
- 69. Build process: Validation (Tidy, JSLint) Minification (JSMin, CSS minifier) Consolidation (one CSS and one JS instead of dozens) Tagging as “live code”
- 71. Find creative outlets for team members.
- 72. Let them create reusable components identified in code reviews.
- 74. Lightning Talks: 5 Minutes presentation 5 minutes demo 5 minutes discussion Every Thursday 11.45 – 12.00
- 75. If your company is clever, it’ll share these finds with the world.
- 76. So how do you plan JavaScript and Ajax for larger teams?
- 77. Get the team to talk and agree on what works best.
- 79. Architect your JavaScript: Modules instead of views / pages / sections
- 80. Architect your JavaScript: Modules instead of views / pages / sections Skins for each module (JS,non-JS state)
- 81. Architect your JavaScript: Modules instead of views / pages / sections Skins for each module (JS,non-JS state) Configuration options for each module.
- 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.
- 83. Involve Design and Engineering in the process and explain the rationale of your plan.
- 84. Communication and sharing information is better than any architectural blueprint you or I could come up with.
- 85. THANKS! Christian Heilmann http://wait-till-i.com [email_address]