Ustream vs Legacy, It's never too late to start your fight! Jsist 2014

http://www.slideshare.net/matenadasdi1/ustream-vs-legacy-js-ist-2014

A general talk about Ustream's revolution on our aging codebase. We had to make critical changes on our codebase to achieve more stability and scalability on the client side.
This talk is about encouragement with lot of tips and tricks if you are in a similar legacy situation.

Transcript

1. Ustream vs Legacy @matenadasdi
2. Ustream basics 80.000.000 visitors / month 5.000.000+ viewer hours on tough days
3. Legacy is not bad code, it’s just old or over-iterated
4. Everyone starts in the dark… but there is always light in the end of the tunnel
5. Our goal was to achieve more stability and scalability in our frontend codebase
6. Our situation was (like every frontend codebase some years ago) no tests no modules all-in-one feature based class system poor abstraction JSLint as “code quality tools”
7. It’s a new ERA it’s a heaven of tools and new solutions for frontend developers nowadays
8. we had 5 stages in our long journey it may help or inspire you too
9. Structure
10. separate business logic from its representation easy isolation dependency injection we had to create / use a new structure There are some must-have things for testing…
11. not the framework, the way of thinking matters
12. always think in layers with separated responsibilities
13. Sync Socket (full-duplex) Async get data set data DOM AJAX WebStorage Cookies Socket Ustream Flash API Longpoll Embeds Views manipulates events Controllers control notify Logics Models get data set data
14. our new small framework is under 10kb but we had millions of lines written in an old style
15. don’t be afraid to start the hardcore continuous integration
16. Testing
17. Mocha + Chai framework: Node and Browser support Separated assert libraries Tons of reporters mocking: SinonJS Spies, Stubs, Mocks Assertions for invocations wide framework support Faking AJAX, server module dependency mocking: SquireJS Dependency injector for RequireJS mock / store Unit testing
18. Unit testing is a must in every architecture but it’s not enough for client side code!
19. Testing real browser functionality with mocking and simulating the DOM can be a pain in the …
20. Node.js based navigation scripting PhantomJS / SlimerJS support screenshot capture you can skip or use your own testing framework Solution: CasperJS
21. Right now we have: parallel execution thanks to an own grunt task solution Tools based on Casper: Screenshot comparisan tool, regression testing (PhantomCSS) own testing wrapper layer with different presets and transparent modules. User.login(), etc. It’s really flexible and easy to customize!
22. Automation
23. Manual processes simply won’t work… but there is an easy cure!
24. GRUNT || GULP we use Grunt! Why not gulp? Bad question, both are awesome, move on, and pick one!:)
25. we could migrate our old PHP / Ruby / etc. based frontend jobs to Node there is a transparent layer for every frontend related task thanks to our dynamic GruntFile.js solution, adding new tasks is fast Thanks to Grunt
26. CI integration is important! with an automation layer, it’s easy to do
27. Rules & standards insurance for the future
28. Follow your rules, because if you break them, they are not rules anymore…
29. Code style!
30. JSHint ! ! pros: .jshintrc huge community wide IDE / Text editor integration grunt / gulp plugins ! cons: still regexp based (JSLint fork) not pluginable nearly impossible to write semantic rules
31. ESLint ! pros: pluginable tons of new rules rapidly growing community semantics ESPRIMA growing IDE / Text editor integration ! cons: you can tell maybe!
32. We’ve created our own rules
33. Complexity? Lines of code (LOC) Halstead indexes Maintainability index Cyclomatic complexity linearly independent paths in the method
34. JSComplexity & Plato We run complexity report in Jenkins nightly build for our whole JS codebase https://www.npmjs.org/package/complexity-report Plato is a great tool for manual examinations https://github.com/es-analysis/plato
35. Use your CI or Git hooks to force your rules & standards
36. Modules, modules!
37. async module loading dependency injection project based SOA workflow, we have to avoid code duplication in several repos/projects Why we’ve started our modularisation marathon
38. Do not worry! Code modifications can be automated! http://esprima.org/ { "type": "Program", "body": [ { "type": "VariableDeclaration", "declarations": [ { "type": "VariableDeclarator", "id": { "type": "Identifier", "name": "city" }, "init": { "type": "Literal", "value": "istanbul", "raw": "'istanbul'" } } ], "kind": "var" }, { "type": "IfStatement", "test": { "type": "BinaryExpression", "operator": "===", "left": { "type": "Identifier", "name": "city" }, "right": { "type": "Literal", "value": "istanbul", "raw": "'istanbul'" } }, "consequent": { var city = ‘istanbul’; ! if (city === ‘istanbul’) { conf = 'jsist'; }
39. NPM modules? Maybe private ones? more!
40. private repo server: Sinopia internal GitLab repos for each package grunt release task for NPM module release NPM in private https://github.com/geddski/grunt-release https://github.com/boennemann/grunt-semantic-release
41. Why? we can manage our dependencies in different projects / services separated tests & documentation for each module we also use NPM for non-node package management Yeoman for automated project configuration
42. That’s not dark anymore!:) This is where we are right now!
43. What we’ve achieved so far 600+ modules created hundreds of unit tests and Casper tests, and growing rapidly new and important core features are moved to the new structure we started to create our private NPM modules like hell! ready for Async module loading
44. Remember: It’s never too late! @matenadasdi