Skip to content

Latest commit

 

History

History
78 lines (66 loc) · 4.21 KB

ENG-README.md

File metadata and controls

78 lines (66 loc) · 4.21 KB
Raw

Playbook

Codestyle, conventions, etc. for Rubynor

Version Control

  • Use feature branches. The branch name must be in kebab case (my-super-branch, not my_super_branch). The name must clearly describe what the change consists of.
  • Commits should preferably do one thing.
  • Use meaningful commit messages. Remember that commit messages are a help to people who read the code and try to understand why things are done. Good examples: Bug fix: The representative jumps to the bottom of the list when they are updated, Tables for meetings, Make the login button more visible in the menu. Bad examples: Fixed a bug, WIP: Trying to fix representatives

Checklist before making a pull request

  • Read the diff on Github before creating the PR and see if you find any errors
  • Is there an incorrect code here? In that case - remove.
  • Are there print statements and other debug here? In that case - remove.
  • If there are migrations:
    • Do they have a reasonable name?
    • Will they work without having to reset the database?
    • Have you updated seed data?
    • Have you migrated existing data? (Example: If you add a constraint that all Meetings must have a status, you must ensure that all current meetings also get a status)
  • Do new fields have reasonable default values? In particular: do boolean fields have a default value?
  • Does the pull request cover one and only one change? If not, consider splitting up your PR in several.
  • Have you introduced new n + 1 queries?
  • Have you put indexes on all database fields that you access?
  • Have you added all the files?
  • Have you removed autogenerated files (especially from rails generate)?
  • Have you used variables, method parameters, gems, imports etc earlier that you forgot to remove?
  • Are the tests running green?
  • Have you written new tests for the changes you have made?
  • Have you tested that it works locally on your own machine?
  • Have you thought of all edge cases?
  • Is the branch rebased against the last master?
  • Have you accidentally introduced anything by a merge / rebase that should not be there?

Checklist after making a pull request

  • Does Semaphore complain about anything?
  • Does Code Climate complain about something?
  • Does the review app work?

When the PR is ready for review

  • Put the card in the "review" column in Trello
  • Notify Slack that there is a PR ready for review
  • Get feedback from at least one reviewer. Correct mistakes. Ask if there's anything you're wondering about.
  • Notify the other people in the project in Slack when you are ready for a new review
  • Continue with this cycle until a reviewer approves your PR for merging
  • Rebase to merge master with your branch
  • Check that things still work; locally and in the review app
  • Merge the result of that into master
  • Check that it now works on staging, since master automatically deploys there
  • Delete the branch when it is merged
  • Promote staging to production
  • Move the card to the 'done'-column in Trello

Checklist if you have promoted staging to production

  • Have you run rails db: migrate if there are database changes?
  • Have you checked that it works? If there are two or more "user types", check as everyone
  • Have you added anything that requires setup on Heroku? For example, for the first deploy that uses email, SendGrid or similar must be set up

Style Guide

Rails

Follow https://github.com/thoughtbot/guides/tree/master/style/rails

Ruby

Follow https://github.com/thoughtbot/guides/tree/master/style/ruby

Tools

Trello columns

  • Backlog/TODO (scheduled tasks)
  • Doing (What you are working at right now)
  • Review (tasks in PR review)
  • Done
  • In production since last customer meeting
  • In production

Conventions

  • Remember to assign yourself to a task when you get started (and not long before)
  • Before you take a new task - be absolutely sure you do not get on with the one you are already working on and that what you are doing is completely done, according to this guide
  • When it's you who have programmed the task, it's your responsibility to make sure it's all the way to production - it includes wondering if people do not give you code review and actually pushe things to the staging and production environment (and test that it works when it is in these environments)