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. https://speakerdeck.com/matenadasdi/ustream-vs-legacy-its-never-too-late-to-start-your-fight-jsist-2014

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. There are some must-have things for testing…
separate business logic from its representation
easy isolation
dependency injection
we 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. DOM
manipulates events
Views
control notify
Controllers
get data set data
Logics Models
get data set data
Async Sync Socket (full-duplex)
AJAX WebStorage Cookies Socket Longpoll Ustream Flash API Embeds

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. framework:
Mocha + Chai
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. Solution: CasperJS
Node.js based navigation scripting
PhantomJS / SlimerJS support
screenshot capture
you can skip or use your own testing framework

21. It’s really flexible and easy to customize!
Right now we have:
parallel execution thanks to an own grunt task solution
Tools 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 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. Thanks to Grunt
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

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. Why we’ve started our modularisation marathon
async module loading
dependency injection
project based SOA workflow, we have to avoid code duplication in
several repos/projects

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. more!
NPM modules? Maybe private ones?

40. NPM in private
private repo server: Sinopia
internal GitLab repos for each package
grunt release task for NPM module release
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. This is where we are right now!
That’s not dark anymore!:)

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