Planning JavaScript for Larger Teams - Draft & Handout version

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

Slide 2: 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 3: Do not fiddle with other people’s knobs unless you know what you are doing.

Slide 4: Spoilers: –Some of the following advice will seem very basic to you. –This is not based on me thinking you need this. –It is meant as a reminder. Next time you encounter these problems you won’t have to think about them. … and Harry Potter dies, but comes back using a magic stone which is a third of the Deathly Hallows.

Slide 5: There is one main fatal mistake any developer can make:

Slide 6: There is one main fatal mistake any developer can make: Make assumptions

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

Slide 8: “Surely this has been done already, and by people better than me.”

Slide 9: “This works right now, there won’t be a need to change it.”

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

Slide 11: “We hack that now, and will get time later to fix it.”

Slide 12: “This is a minor issue only for this instance, no need to file a bug.”

Slide 13: All these mistakes are yours to make.

Slide 14: Sometimes they need to be made in order to prove a new point or prove an issue and its solution.

Slide 15: However, avoiding them means you help all of us working together.

Slide 16: No more heroes!

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

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

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

Slide 20: Web products are never finished.

Slide 21: Don’t leave a mess behind; work as if you won’t see the code ever again.

Slide 22: Mistakes we make:

Slide 23: 1. Mixing structure, presentation and behaviour. 2. Trusting the browser. 3. Trusting the markup. 4. Not planning for inclusion. 5. Not planning for failure. 6. Premature optimization.

Slide 24: This should be a no- brainer by now but we still do it.

Slide 25: Separation means: –Working in parallel (to an extend) –Re-skinning an application by changing the style sheet –Caching, Minimizing, Optimizing for speed and delivery.

Slide 26: Not separating means: –Harder maintenance –Larger and slower sites –Several sources for bugs without an easy way to track them.

Slide 28: The last thing to trust is the browser.

Slide 29: They all have shifty eyes and will steal your loose change when you don’t look.

Slide 30: Testing for a browser name and assuming it can do certain things is a bad plan.

Slide 31: Browsers come in all kind of setups and with all kind of extensions.

Slide 32: Assume the browser will fail and keep poking it until it tells you all is OK.

Slide 33: Making assumptions: function showMessage(elm, message){ elm.firstChild.nodeValue = message; }

Slide 34: function showMessage(id,message){ if(document.getElementById){ var elm = document.getElementById(id); if(elm){ if(elm.firstChild){ if(elm.firstChild.nodeType === 3){ elm.firstChild.nodeValue = message; } else { var t = document.createTextNode(message); elm.insertBefore(t,elm.firstChild); } } else { var t = document.createTextNode(message); elm.appendChild(t,elm.firstChild); } } } }

Slide 44: Bit overkill, isn’t it?

Slide 45: –Add tests for the browser early (init method) –Use library functions that do the testing for you.

Slide 47: HTML markup of the document is never set in stone.

Slide 48: Don’t rely on it.

Slide 49: document.getElementBy Id('nav').getElements ByTagName('li')[3].fi rstChild.getElmentsBy TagName('span')[2].no deValue = 'offline';

Slide 50: document.getElementBy Id('nav').getElements ByTagName('li')[3].fi rstChild.getElmentsBy TagName('span')[2].no deValue = 'offline';

Slide 52: Assuming your script is the only one included in the document:

Slide 53: Assuming your script is the only one included in the document: hasfail = true;

Slide 54: Namespace your scripts, follow a naming convention and don’t leave any global variables or methods.

Slide 55: That way your script will run even if it has to work alongside bad code.

Slide 56: Bad code will be added to your documents, most of the time in the form of advertisements or tracking code.

Slide 58: Things will fail, plan for it! –JavaScript will not be available. –Ajax connections will take too long or return wrong data. –Plan for a fallback option (redirect to a static page, show an error message)

Slide 59: <a href="javascript:ajaxmagic('panda')"> Show results for 'panda' </a>

Slide 60: <a href="javascript:ajaxmagic('panda')"> Show results for 'panda' </a>

Slide 61: <a href="search.php?term=panda" id="searchlink"> Show results for 'panda‘ </a> var YE = YAHOO.util.Event; YE.on('searchlink','click',ajaxmagic); function ajaxmagic(e){ var t = YE.getTarget(e); var url = t.href.split('=')[1]; ajaxcode(url); YE.preventDefault(e); }

Slide 62: Re-use the backend script function ajaxmagic(e){ var t = YE.getTarget(e); var url = t.href + &output=json'; ajaxcode(url); YE.preventDefault(e); }

Slide 64: Each of us has a little hacker inside who wants to get out.

Slide 65: This little hacker wants to make things as fast, small and cool as possible.

Slide 66: This little hacker is also very competitive and doesn’t trust reused code or libraries.

Slide 68: Our job is not to give in to it when we produce production code.

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

Slide 70: It needs to be understandable and maintainable.

Slide 71: –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 72: Enough bad. Give us some tips!

Slide 73: 1. Follow a diet plan. 2. Have a build process. 3. Have a code standard and documentation process. 4. Review and reuse code. 5. Plan for extension. 6. Think maintenance

Slide 74: Try to avoid traps that make your code hungry: –Cut down on DOM interaction –Minimize the amount of loops –Build tool methods to deal with reoccurring problems

Slide 75: Use shortcut notations in JavaScript.

Slide 76: var links = new Array(); links[0]='http://icant.co.uk'; links[1]='http://wait-till-i.com'; links[2]='http://onlinetools.org';

Slide 77: var links = new Array(); links[0]='http://icant.co.uk'; links[1]='http://wait-till-i.com'; links[2]='http://onlinetools.org'; var links = [ 'http://icant.co.uk', 'http://wait-till-i.com', 'http://onlinetools.org‘ ];

Slide 78: var contact = new Object(); contact.name = 'Christian'; contact.surName = 'Heilmann'; contact.age = 32; contact.hair = 'slightly red';

Slide 79: var contact = new Object(); contact.name = 'Christian'; contact.surName = 'Heilmann'; contact.age = 32; contact.hair = 'slightly red'; var contact = { name:'Christian', surName:'Heilmann', age:32, hair:'slightly red' };

Slide 80: if(hasCheeseburger){ cat.mood = 'happy'; } else { cat.mood = 'sad'; }

Slide 81: if(hasCheeseburger){ cat.mood = 'happy'; } else { cat.mood = 'sad'; } cat.mood = hasCheeseburger?'happy':'sad';

Slide 82: if(hasCheeseburger){ cat.mood = 'happy'; } else { cat.mood = 'sad'; } cat.mood = hasCheeseburger?'happy':'sad'; condition

Slide 83: if(hasCheeseburger){ cat.mood = 'happy'; } else { cat.mood = 'sad'; } cat.mood = hasCheeseburger?'happy':'sad'; true case

Slide 84: if(hasCheeseburger){ cat.mood = 'happy'; } else { cat.mood = 'sad'; } cat.mood = hasCheeseburger?'happy':'sad'; false case

Slide 85: if(obj.getClass()==='full'){ var x = screen.left; } else { var x = current; }

Slide 86: if(obj.getClass()==='full'){ var x = screen.left; } else { var x = current; } var x = (obj.hasClass()==='full') ? screen.left : current;

Slide 87: var cat; if(canHasCheeseburger){ cat = canHasCheeseburger; }; if(garfield){ cat = garfield; };

Slide 88: var cat; if(canHasCheeseburger){ cat = canHasCheeseburger; }; if(garfield){ cat = garfield; }; var cat = canHasCheeseburger || garfield;

Slide 89: var cat; if(canHasCheeseburger){ cat = canHasCheeseburger; }; if(garfield){ cat = garfield; }; var cat = canHasCheeseburger || garfield; one or the other, defining a fallback

Slide 90: var massive.name.with.long.namespace = { ...private stuff... return{ init:function(){ massive.name.with.long.namespace.show(); }, show:function(){ massive.name.with.long.namespace.test(); }, test:function(){ } } }();

Slide 91: var massive.name.with.long.namespace = { var pub = {}; ...private stuff... pub.init = function(){ pub.show(); }; pub.show = function(){ pub.test(); }; pub.test = function(){ }; return pub; }(); massive.name.with.long.namespace.init();

Slide 92: var massive.name.with.long.namespace = { function init(){ show(); }; function show(){ test(); }; function test(){ }; return { init:init; show:show; test:test; }; }(); massive.name.with.long.namespace.init();

Slide 94: –Production code is not live code. –That doesn’t happen on the back-end and it shouldn’t happen on the front-end. –Live code is there for machines, production code is there for humans.

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

Slide 97: Following a code standard means you can: –Assess quality of code –Find bugs easily and create reproducible bug reports –Have quick handover from developer to developer –Have reliable version control

Slide 98: What code standard?

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

Slide 100: Document it and other teams can validate what you have done.

Slide 101: In the perfect world, we’ll all follow the same code standard.

Slide 102: Let’s meet again in a year! :-)

Slide 103: Comments are good, but they are not documentation.

Slide 104: Write documentation in peer review - as the developer you are too close to the subject.

Slide 105: Plan and ask for time to document what you have done.

Slide 107: Conduct Code reviews –You find problems and solutions you can share in the team. –You find out who knows what well and who needs training in what –You share the knowledge throughout the team = no Divas.

Slide 108: –If you keep finding the same problem and different solutions for it, find a generic solution and re-use that one. –Look at what other people have done (libraries). –Bounce your solutions off other development teams.

Slide 109: 1. Follow a diet plan. 2. Have a build process. 3. Have a code standard and documentation process. 4. Review and reuse your code. 5. Plan for extension. 6. Think maintenance

Slide 110: Whenever you write some code, don’t think that your implementation will be the end of it.

Slide 111: Make sure that your code can be extended by other people and try to build it as modular as possible.

Slide 112: 1. Follow a diet plan. 2. Have a build process. 3. Have a code standard and documentation process. 4. Review and reuse your code. 5. Plan for extension. 6. Think maintenance

Slide 113: Not everybody maintaining your code will be as good as you are.

Slide 114: Trying to find where to change what in a piece of code is terribly frustrating.

Slide 115: Separate out as much of the look and feel as you can.

Slide 116: Also separate out labels that are likely to change and the names of CSS classes and IDs in use.

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

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

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

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

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

Slideshare.net (beta)