This repo provides best-practice guidelines you'll be expected to follow when developing projects at Stylist. Depending on the application you may notice some rules documented here aren't stricly enforced which is especially true for legacy applications. All new projects or applications should be developed according to the rules documented here.
Assign at least two (or more) developers to your PR, and always endeavour to read anything you're assigned, even if it's not your core focus. In general we write JavaScript, C# and PHP, and it's all code at the end of the day. We've found that the PR is a great place to learn and discuss functionality.
If the project you're working on doesn't have one, please add one!
You're only an SSD failure or a pub thief away from having your work lost, there's no reason not to commit and push things up!
At Stylist we favour the git branching model developed by Vincent Driessen – sometimes referred to as git flow (although that name actually refers to a set of CLI tools developed to help with the branching operations for this model).
If this is unfamiliar to you, he has an excellent write up explaining it all in detail. It will be beneficial to familiarise yourself with this, so that you understand the rationale behind it and what its aims are.
Below is a diagram showing the outline of the model:
Depending on the application we usually have 3 deployment environments:
Production – this is the live site, deployed from a tagged/published master branch – considered 'stable'.
Preprod and/or Staging – this usually contains master branch, this is where we perform QA, apply fixes and verify that all is ok before deploying to production
Develop or PR - typically contains work in progress...
Document everything. If possible, write documentation before you even start coding. Where appropriate, make sure your project's documentation covers :
- functional specification (as a user I can...)
- technical specification (flow diagrams, infrastructure requirements)
- detailed instruction of how to use and set up locally (repo's README.md)
When developing APIs use tools like API Blueprint or Swagger.
When developing code, document interfaces/contracts, classes and methods using syntax specific to the programming language choosen:
Test Driven Development approach is recommended but it's not mandatory. You will however be expected to write a testable code according to SOLID and DRY principles. There's a lot of tutorials and resources available online about how to write a testable code. One example can be found here.
At Stylist you'll be responsible for writing unit and integration tests for new and existing applications as well as e2e tests where appropriate.
At Stylist we don't currently enforce strict coding style guides, however you'll be expected to write clean code according to best practice rules specific to the programming language choosen: