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

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

Post on 14-Jun-2015




0 download

Embed Size (px)


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.


<ul><li> 1. Ustream vs Legacy@matenadasdi</li></ul> <p> 2. Ustream basics80.000.000 visitors / month5.000.000+ viewer hours on tough days 3. Legacy is not bad code, its just old or over-iterated 4. Everyone starts in the darkbut there is always light in the end of the tunnel 5. Our goal was to achievemore stability and scalabilityin our frontend codebase 6. Our situation was(like every frontend codebase some years ago)no testsno modulesall-in-one feature based class systempoor abstractionJSLint as code quality tools 7. Its a new ERAits a heaven of tools and new solutionsfor frontend developers nowadays 8. we had 5 stages in our long journeyit may help or inspire you too 9. Structure 10. There are some must-have things for testingseparate business logic from its representationeasy isolationdependency injectionwe had to create / use a new structure 11. not the framework, the way of thinking matters 12. always think in layers with separated responsibilities 13. DOMmanipulates eventsViewscontrol notifyControllersget data set dataLogics Modelsget data set dataAsync Sync Socket (full-duplex)AJAX WebStorage Cookies Socket Longpoll Ustream Flash API Embeds 14. our new small framework is under 10kbbut we had millions of lines written in an old style 15. dont be afraid to start the hardcore continuous integration 16. Testing 17. framework:Mocha + ChaiNode and Browser supportSeparated assert librariesTons of reportersmocking:SinonJSSpies, Stubs, MocksAssertions for invocationswide framework supportFaking AJAX, servermodule dependency mocking:SquireJSDependency injector forRequireJSmock / storeUnit testing 18. Unit testing is a must in every architecturebut its not enough for client side code! 19. Testing real browser functionality with mockingand simulating the DOM can be a pain in the 20. Solution: CasperJSNode.js based navigation scriptingPhantomJS / SlimerJS supportscreenshot captureyou can skip or use your own testing framework 21. Its really flexible and easy to customize!Right now we have:parallel execution thanks to an own grunt task solutionTools based on Casper: Screenshot comparison tool, regression testing (PhantomCSS)own testing wrapper layer with different presets and transparent modules. User.login(), etc. 22. Automation 23. Manual processes simply wont workbut there is an easy cure! 24. GRUNT || GULPwe use Grunt!Why not gulp?Bad question, both are awesome, move on, and pick one!:) 25. Thanks to Gruntwe could migrate our old PHP / Ruby / etc. based frontend jobs to Nodethere is a transparent layer for every frontend related taskthanks to our dynamic GruntFile.js solution, adding new tasks is fast 26. CI integration is important!with an automation layer, its easy to do 27. Rules &amp; standardsinsurance for the future 28. Follow your rules, because if you break them,they are not rules anymore 29. Code style! 30. JSHint!!pros:.jshintrchuge communitywide IDE / Text editor integrationgrunt / gulp plugins!cons:still regexp based (JSLint fork)not pluginablenearly impossible to write semantic rules 31. ESLint!pros:pluginabletons of new rulesrapidly growing communitysemanticsESPRIMAgrowing IDE / Text editor integration!cons:you can tell maybe! 32. Weve created our own rules 33. Complexity?Lines of code (LOC)Halstead indexesMaintainability indexCyclomatic complexitylinearly independent paths in the method 34. JSComplexity &amp; PlatoWe run complexity report in Jenkins nightly build for our whole JS codebase is a great tool for manual examinations 35. Use your CI or Git hooks to force your rules &amp; standards 36. Modules, modules! 37. Why weve started our modularisation marathonasync module loadingdependency injectionproject based SOA workflow, we have to avoid code duplication inseveral repos/projects 38. Do not worry! Code modifications can be automated!{"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. more!NPM modules? Maybe private ones? 40. NPM in privateprivate repo server: Sinopiainternal GitLab repos for each packagegrunt release task for NPM module release 41. Why?we can manage our dependencies in different projects / servicesseparated tests &amp; documentation for each modulewe also use NPM for non-node package managementYeoman for automated project configuration 42. This is where we are right now!Thats not dark anymore!:) 43. What weve achieved so far600+ modules createdhundreds of unit tests and Casper tests, and growing rapidlynew and important core features are moved to the new structurewe started to create our private NPM modules like hell!ready for Async module loading 44. Remember: Its never too late!@matenadasdi </p>