There are three points in the blog post.
- How to debug the code
- Performance tuning
How to share the code in a team
- Standardize basic library. (e.g., jQuery, Prototype.js, etc.) That means use one basic library in a page.
- Have naming convention (for example, class name must be written in camel case, use prefix ‘opt_’ for arguments which is omissible.)
- Delegate resolving dependency to library
- Emphasize to illustrate concepts to understand it in the team (class oriented style should be good to illustrate the concept in UML)
- Use same form, pattern of coding for complicated process (e.g., deferred)
- Use JSON (hash) for arguments, so that you don’t have to care its order when you call the function
- Write document with JsDoc (or other documentation tool like jsdoc-toolkit
How to debug
- Use assertion. There is an example of function assert which call debugger when the precondition is not filled and its usage (sample) in the page.
- Use conditional breakpoint instead of other debug (e.g., alert, console.log.)
- You don’t need to care about performance from the beginning
- But don’t do make it much slower (e.g., scanning all DOM elements)
- Focus sensible speed first (e.g., give the user enough feedback from the UI. Avoid too much animation.)
- Use profiler (firebug, webkit) to figure out the point of performance problem