Upgrade to Pro — share decks privately, control downloads, hide ads and more …

It's never too late to fight your legacy!

JSIST
September 29, 2014

It's never too late to fight your legacy!

JSIST 2014
By : Máté Nádasdi
http://jsist.org

JSIST

September 29, 2014
Tweet

More Decks by JSIST

Other Decks in Programming

Transcript

  1. 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”
  2. It’s a new ERA it’s a heaven of tools and

    new solutions for frontend developers nowadays
  3. 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…
  4. 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
  5. our new small framework is under 10kb but we had

    millions of lines written in an old style
  6. 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
  7. Node.js based navigation scripting PhantomJS / SlimerJS support screenshot capture

    you can skip or use your own testing framework Solution: CasperJS
  8. 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!
  9. GRUNT || GULP we use Grunt! Why not gulp? Bad

    question, both are awesome, move on, and pick one!:)
  10. 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
  11. 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
  12. ESLint ! pros: pluginable tons of new rules rapidly growing

    community semantics ESPRIMA growing IDE / Text editor integration ! cons: you can tell maybe!
  13. Complexity? Lines of code (LOC) Halstead indexes Maintainability index Cyclomatic

    complexity linearly independent paths in the method
  14. 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
  15. 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
  16. 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'; }
  17. 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
  18. 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
  19. 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