Planning JavaScript and Ajax for larger teams

13,937 views

Published on

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.

Published in: Technology
4 Comments
15 Likes
Statistics
Notes
  • Absolutely awesome presentation. One sane head that will separate the value from the junk. MUST READ for EVERY WEB DEVELOPER.
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • Kaa, yes and no - I made my point clearer in my talk. What I was saying is that you shouldn't go on and create something that has been done before and does the job just because you can do it better whilst being in the development cycle. Furthermore I pointed out that it does make sense to change code but a lot more so after you talked it through in the team.

    This is also where the first assumption comes into play: don't hold back if you think there should be a change, tell the team about it.

    I will cease to use 'reinvent the wheel', it is a terribly loaded and overused expression.<br /><br/>
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • to avoid == “Surely this has been done before - and by people better than me.”
    to do =='Don’t reinvent the wheel even if you consider yours superior.'

    are these two statements not slightly contradictory?<br /><br/>
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • Thanks a lot Chris for uploading this one! This _is_ good stuff.<br /><br/>
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
No Downloads
Views
Total views
13,937
On SlideShare
0
From Embeds
0
Number of Embeds
489
Actions
Shares
0
Downloads
329
Comments
4
Likes
15
Embeds 0
No embeds

No notes for slide

Planning JavaScript and Ajax for larger teams

  1. Planning JavaScript and Ajax for larger teams Christian Heilmann @media Ajax, London, November 2007
  2. <ul><li>This is awesome! </li></ul>
  3. <ul><li>Here we are at a conference about JavaScript </li></ul><ul><li>(oh well, Ajax) </li></ul>
  4.  
  5. DOM Scripting Task Force
  6. DOM Scripting Task Force
  7. <ul><li>We’ve done it. </li></ul><ul><li>JavaScript is cool again and people take it much more serious. </li></ul>
  8. <ul><li>Now it is time to make it mature. </li></ul>
  9. <ul><li>We do that in a technical manner. </li></ul>
  10. <ul><li>The technical part will get a solution. </li></ul>
  11. <ul><li>However, danger lurks around every corner. </li></ul>
  12. <ul><li>How we can make JavaScript and Ajax solutions work with larger teams? </li></ul>
  13. <ul><li>The first step is to stop making assumptions. </li></ul>
  14. 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>
  15. <ul><li>“Do not fiddle with other people’s knobs unless you know what you are doing.” </li></ul>
  16. <ul><li>JavaScript is not magic and should not be confusing and difficult. </li></ul>
  17. <ul><li>Most of the time it is confusing because of other assumptions. </li></ul>
  18. <ul><li>Let’s take a look at some of them: </li></ul>
  19. <ul><li>“ I don’t need to tell people that - they know already.” </li></ul>
  20. <ul><li>“ Surely this has been done before - and by people better than me.” </li></ul>
  21. <ul><li>“ This works right now. There won’t be a need to change it.” </li></ul>
  22. <ul><li>“ This never worked in the past - it won’t work now.” </li></ul>
  23. <ul><li>“ This is a minor issue only for this instance – there’s no need to file a bug.” </li></ul>
  24. <ul><li>“ Hack that now and we’ll get time later to fix it.” </li></ul>
  25. <ul><li>These are all things we need to avoid. </li></ul>
  26. <ul><li>JavaScript and Ajax are a part of the normal development cycle. </li></ul>
  27. <ul><li>They cannot be bolted on at the end by super-human developers. </li></ul>
  28. <ul><li>They are as much an accessibility and usability task as the rest of the interface is. </li></ul>
  29. <ul><li>No more heroes! </li></ul>
  30. <ul><li>A good developer is not a very gifted and impressive developer. </li></ul>
  31. <ul><li>It is a developer that can work with others and works for the next developer to take over. </li></ul>
  32. <ul><li>People will move from product to product or leave the company. </li></ul>
  33. <ul><li>Web products are never finished. </li></ul>
  34. <ul><li>It is time to advertise working as if you won’t ever see the code again. </li></ul>
  35. <ul><li>How? </li></ul>
  36. <ul><li>Following a code standard </li></ul>
  37. <ul><li>Following a code standard </li></ul><ul><ul><li>you can assess the quality of code </li></ul></ul>
  38. <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>
  39. <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>
  40. <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>
  41. <ul><li>What code standard? </li></ul>
  42. <ul><li>Whatever the team agrees on and feels comfortable with. </li></ul>
  43. <ul><li>Make sure to have a reason for your code standards. </li></ul>
  44. <ul><li>Take time to train each new hire on them. </li></ul>
  45. <ul><li>How can you find reasonable standards? </li></ul>
  46. <ul><li>Conduct Code reviews </li></ul>
  47. <ul><li>Conduct Code reviews </li></ul><ul><ul><li>You find problems and solutions. </li></ul></ul>
  48. <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>
  49. <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>
  50. <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>
  51. <ul><li>Doesn’t that stop innovation? </li></ul>
  52. <ul><li>Nein. </li></ul>
  53. <ul><li>Development time is not the time to innovate or change. </li></ul>
  54. <ul><li>Don’t listen to the </li></ul><ul><li>“ inner hacker”. </li></ul>
  55.  
  56. <ul><li>Production code does not need to be optimized from the start. </li></ul>
  57. <ul><li>It needs to be understandable and maintainable. </li></ul>
  58. <ul><ul><li>use library code, even if it appears huge (a lot of the size is a myth) </li></ul></ul>
  59. <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>
  60. <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>
  61. <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>
  62. <ul><ul><li>Production code is for humans. </li></ul></ul>
  63. <ul><ul><li>Production code is for humans. </li></ul></ul><ul><ul><li>Live code is for machines. </li></ul></ul>
  64. <ul><ul><li>In between, we have a build process. </li></ul></ul>
  65. <ul><li>Build process: </li></ul>
  66. <ul><li>Build process: </li></ul><ul><ul><li>Validation (Tidy, JSLint) </li></ul></ul>
  67. <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>
  68. <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>
  69. <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>
  70. <ul><li>What about playtime? </li></ul>
  71. <ul><li>Find creative outlets for team members. </li></ul>
  72. <ul><li>Let them create reusable components identified in code reviews. </li></ul>
  73. <ul><li>Foster internal communication. </li></ul>
  74. <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>
  75. <ul><li>If your company is clever, it’ll share these finds with the world. </li></ul>
  76. <ul><li>So how do you plan JavaScript and Ajax for larger teams? </li></ul>
  77. <ul><li>Get the team to talk and agree on what works best. </li></ul>
  78. <ul><li>Architect your JavaScript: </li></ul>
  79. <ul><li>Architect your JavaScript: </li></ul><ul><ul><li>Modules instead of views / pages / sections </li></ul></ul>
  80. <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>
  81. <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>
  82. <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>
  83. <ul><li>Involve Design and Engineering in the process and explain the rationale of your plan. </li></ul>
  84. <ul><li>Communication and sharing information is better than any architectural blueprint you or I could come up with. </li></ul>
  85. <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>

×