Automatic constraints as a team maturity accelerator for startups
•
2 likes•3,557 views
How we use automated constraints at iAdvize, Redsmin and Bringr to bring up to speed our teams maturity and efficiency as well as improving the overall project quality. http://blog.fgribreau.com/2015/10/automatic-constraints-as-team-maturity.html
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Similar to Automatic constraints as a team maturity accelerator for startups
Similar to Automatic constraints as a team maturity accelerator for startups (20)
More from François-Guillaume Ribreau
More from François-Guillaume Ribreau (16)
Recently uploaded
Recently uploaded (20)
Automatic constraints as a team maturity accelerator for startups
- 1. Automatic constraints as a team maturity accelerator for startups
- 4. Bringr Leader européen de l'engagement client en temps réel. (click2chat, click2call, click2video, community, ...) #sold
- 5. Bringr
- 6. Developer oriented real-time monitoring and administration service for Redis
- 7. LET ME TELL YOU A STORY...
- 9. A growing startup... = a lot of newcomers = ever changing directions = need to move fast
- 10. [Where, How, What to follow] to start?
- 11. - How to start alone a new project? - Where are the conventions? - What are the best practices? - How can I quickly start on a new language? - How to setup my dev. env? - How to deploy in production?
- 12. Only one quality guard: code reviews
- 13. PROBLEM
- 15. SOLUTION
- 16. Let’s create conventions! ... or how to add a new problem on top of another
- 23. Okay. So what’s the workflow now?
- 24. read conventions write code production ready memorise conventions pass the code-review Hard learning curve & easy to forgot conventions while writing code
- 27. Only one quality guard: code reviews blabla ... blabla ...
- 28. (...
- 29. Why not add tests ? #tradeoff
- 30. ...)
- 31. Even with conventions, It’s still hard to detect issues in code-reviews - code-style - undefined variables - misused functions - wrong types - DRY/SoC respect - security - project structure - file naming...
- 32. Does conventions mean scalability ?
- 33. Nope.
- 36. It does. not. scale. - learning curve is too hard - too hard for newcomers on other projects - conventions grow too fast - technology is moving faster than conventions
- 37. SOLUTION
- 38. Don't rely on principle, rely first on automation.
- 41. jscs
- 42. .jscsrc
- 43. jscs
- 46. .eslintrc
- 47. Eslint
- 48. Eslint
- 51. JSInspect Match - 2 instances - ./domain/DateRangeInterval.ValueObject.js:35,37 + ./domain/MeasurementQuery.ValueObject.js:205,207 if (!_.isObject(req) || !req || !_.isObject(req.query)) { return new PrettyError(400, 'Invalid request'); }
- 54. Still.
- 55. - when & how to run these checks? - how to manage legacy code? - how to talk about automated conventions? - how and who choose conventions? - how to be quickly up to speed with new projects/platform/languages?
- 56. when & how to run these checks?
- 57. read conventions write code production memorise them pass code review before
- 58. write code production pass the code review CI automated checks continuous checks after
- 63. how to manage legacy code?
- 64. PROBLEM
- 65. Bringr #monolith
- 66. SOLUTION
- 67. First, don’t feed the damn monolith
- 69. Then, only automate checks on new code
- 70. Bringr Strategy Bringr Impact Bringr Backend .... Bringr Sourcing Bringr Account ... Bringr Alerts Filtering Statistics Rules EnginePublishing Statistics Updater UIUIUI Indexing G+ Vimeo Facebook Youtube Wordpres Twitter Notifications ... ... ... only automate new code
- 71. how to talk about automated conventions
- 72. PROBLEM
- 73. Automating everything can sometimes means less readable conventions & best practices
- 74. .jscsrc
- 75. SOLUTION
- 76. Generate readable documentation from automated tools
- 77. write code production pass the code review CI automated checks continuous checks before
- 78. write code production pass the code review CI continuous checks after readable convention automated checks
- 79. .jscsrcbefore
- 82. how and who choose conventions?
- 89. how to be quickly up to speed with new projects/platform/languages
- 92. CI check-build
- 94. Still.
- 95. You still need to explain the WHY.
- 96. We record internal talks about why we do what we do.
- 100. These automated principles were about code.
- 101. How to spread wider principles? (e.g. application architecture)
- 102. stories2
- 105. @FGRibreau constants files environme nt variables distribut ed Simplicity Genericity Knowing every running environments One configuration to rule them all CONFIGURATION
- 106. @FGRibreau “EVERY CONSTANT NUMBER, BOOLEAN OR STRING* SHOULD BE CONFIGURABLE
- 107. How can we be sure developers will follow this principle?
- 108. Build base libraries Ease the learning curve. Constrain by API design.
- 113. swagger/json-schema/hapi/json-api (Pre-configured in a bootstrap project)
- 115. Everything we just saw makes a common base - leads the developer mindset while coding - brings developers quickly up to speed - flatten issues to cross-language concerns - being able to capitalize on & standardize issues with an adapted tooling is a huge win
- 116. What about non-code principles? E.g. github repository names?
- 118. A cron checks every days repository names. If a developer makes a mistake, he will be notified.
- 120. @FGRibreau Questions? Join us @iAdvize! Don’t forget to take some stickers! Thank you!