1. pre
2. Welcome, thank you for coming in this awful spot before lunch
3. Me, I’m working in... , and part of my job is to review other’s people code. so this talk/rant will be about some simple lessons I’ve learned from code reviews.
4. I'll touch some subjects briefly and leave many of them without explanation, you're welcome to ask questions to clarify
5. I really hope you’ll find it trivial and obvious, it means you’re on the right track
6. Since this is reject js, I decided to have essentially less code than the others speakers, so you can rest
   
7. [next]
   
8. So, clean code, clarity...  is not a nice to have, it’s a requirement, when you working in team. Clean code is a golden mean between smart code and simple code.
9. “Clean code” book
   
10. (Your usually measured by your ability to deliver the stuff, not by how sophisticated or innovative this stuff is)
12. Collaboration on code is a very new craft, 20-30 years old. You don’t have for instance // poets, rhythm... not enough to be dev, you should work in team
13. Github revolution, pull requests and comments
14. (Code review, wtf per minute)
    
15. [next] Expectation for the code before review (what I expect from you and what you should expect from me):
16. Be careful with 3rd parties (backbone-relational story)
18. Nice to have, not expectations, but hopes:
19. all constants -> configs (Address directly static resources (images, paths), selectors and similar)
20. (subjective design remarks, don't sure where to put them)
21. declarative configs are great (yay Backbone events, Aurelien's plugins idea)
22. think twice before choosing the 3rd party lib, because you'll stuck with it, replacement is a lie (Backbone-relatonal story)
    
23. We both shouldn't care about... (admit it, robots can do some stuff better)
24. I don't need detailed documentation either, web is too fast. Show me the code. Only types (because js doesn't have them), if code needs documentation, it's not a good sign
25. All these like a green dog and create a false feeling of participation
    
26. Code review is not a panacea and cannot find all problems (add, add, and you have two identical classes), so look out and communicate about implementations, to prevent conflicts, try to establish pre- or interim design review process or at least guidelines
    
27. Lack of the code-analysis tools (parsers, code coverage, code complexity...), need some love here. If you need some -- please let me know.
    
28. [next]
    
29. Wrappping up, Q&A