Keep your projects tight

Keep your projects tight

How to manage work with large distributed team regarding code consistency, build process and automation

7fa6c608c58feec29a780ba5f7700068?s=128

Kamil Ogórek

November 19, 2013
Tweet

Transcript

  1. Keep your projects tight @kamilogorek

  2. ? Why bother?

  3. Your whole project should look like it was written by

    a single person
  4. Keeping your project tight IS HARD

  5. Working with distributed team IS HARD

  6. Switching between projects IS HARD

  7. Back-end developers world from my perspective

  8. Dedicated teams

  9. Dedicated teams Project specific code conventions

  10. Dedicated teams Project specific code conventions Detailed code review

  11. Dedicated teams Project specific code conventions Detailed code review Dedicated

    teams
  12. Dedicated teams Project specific code conventions Detailed code review Dedicated

    teams Build and deployment process
  13. Dedicated teams Project specific code conventions Detailed code review Dedicated

    teams Build and deployment process Reliable development stack
  14. Meanwhile in a front-end developers world…

  15. Style guides?

  16. Mixed tabs and spaces? Missing semi-colon?

  17. Code review?

  18. Hey guys! There’s this new, cutting-edge thing. Let’s use it,

    even though none of us know anything about it.
  19. Development automation? No! I’m *front-end developer* and i can do

    this myself!
  20. It doesn’t have to be that way ! We already

    have tools that can save us a lot of precious time and highly speed-up our development process
  21. None
  22. Spend some time and think twice about your architecture and

    development process ! It’ll help you in a long run
  23. Style guides and coding conventions

  24. CSS Style guides GitHub: https://github.com/styleguide/css Idiomatic.css: https://github.com/necolas/idiomatic-css Google: http://google-styleguide.googlecode.com/svn/trunk/htmlcssguide.xml

  25. JS Style guides GitHub: https://github.com/styleguide/javascript Idiomatic.js: https://github.com/rwaldron/idiomatic.js/ Google: http://google-styleguide.googlecode.com/svn/trunk/javascriptguide.xml AirBnB:

    https://github.com/airbnb/javascript/
  26. JS Coding Conventions http://sideeffect.kr/popularconvention/#javascript

  27. Editor-config http://editorconfig.org/

  28. Code linting

  29. “modern lint checkers are often used to find code that

    doesn't correspond to certain style guidelines.” http://en.wikipedia.org/wiki/Lint_(software) JSLint: http://www.jslint.com/ ESLint: https://github.com/nzakas/eslint JSHint: http://www.jshint.com/
  30. If there’s a reason to break those rules, do it.

    But always explain why Tip: JS linters respect scope within which you set local changes
  31. Do we really have to do all those things by

    ourselves?
  32. Automation

  33. But wait. Isn’t automation hard? ANT? XML? RAKE? anyone?

  34. GRUNT TO THE RESCUE

  35. GRUNT TO THE RESCUE Easy to configure

  36. GRUNT TO THE RESCUE Easy to configure Plenty of plugins

  37. GRUNT TO THE RESCUE Easy to configure Plenty of plugins

    Writing your own task with no hassle
  38. GRUNT TO THE RESCUE Easy to configure Plenty of plugins

    Writing your own task with no hassle It’s still just JavaScript and Node
  39. Why should i use it?

  40. Why should i use it? Real-time feedback

  41. Why should i use it? Real-time feedback Build process

  42. Why should i use it? Real-time feedback Build process Easy

    deployment
  43. Why should i use it? Real-time feedback Build process Easy

    deployment Saves you time
  44. Real-time feedback

  45. Real-time feedback

  46. Build process/Deployment

  47. how to? http://www.integralist.co.uk/posts/grunt-boilerplate/ https://speakerdeck.com/shaundunne/ grunt-your-way-to-glory-sideview-2013 http://merrickchristensen.com/articles/gruntjs-workflow.html http://gruntjs.com/getting-started

  48. Think about your build process before starting a project and

    verify it before merging anything to repository
  49. pre-commit ! pre-push ! post-update GitHooks

  50. `your-repo/.git/hooks/hook-type` HOW TO? Keep in mind to set executable permissions

    for hook files: `$ chmod +x your-repo/.git/hooks/hook-type`
  51. Ah, and never tell your friends that there’s --no-verify flag!

  52. If you decide to use pre-push hook only, learn how

    to clean up after your work
  53. git commit --amend git rebase --interactive git cherry-pick ARE YOUR

    FRIENDS
  54. Ok, but what if one of developers didn’t set hooks?

    ! Ask Travis for help
  55. Travis CI Lets you monitor status of your repository and

    run specific tasks for every commit ! It’s fully integrated with GitHub Status API
  56. Setting up Enable travis service hook on GitHub repository: https://github.com/your-user/your-repo/settings/hooks

    Create `.travis.yml` in project root And just add test script to package.json
  57. Yup, that’s it 3 steps

  58. And now everyone can see instant feedback

  59. As well as verify whole pull-request

  60. Keep in mind that still, no matter what, people will

    be still making mistakes ! Minimise the risk by allowing machine to do the hard work
  61. Those are only tools They suppose to help you do

    your work, not make it more difficult
  62. Once written stack can be a great codebase for all

    future projects within your company if everyone will respect settled rules
  63. Get a plan and stick to it

  64. Thank you

  65. @kamilogorek meet.js