A few guidelines for peer reviews at Ombu Labs. Be nice, be constructive, suggest alternatives, start discussions, use Git branches, Github pull requests and keep it lean. Make sure that the pull requests solve a concrete problem today. You can always refactor your solution later. Do not design for the future. Keep it simple stupid and learn from the comments in your pull requests.

1. Peer
Review
Ombu Labs, February 2015

2. Git Branches

3. master
It’s production!

4. develop
It’s the unstable branch

5. feature/twitter-integration
It describes a feature

6. hotfixes/price-bug
It describes a bug fix

7. Pull
Requests

8. Title
Brief summary of what it is

9. Description
Longer description of the changes

10. Commits
Make them as granular as possible

11. Code
Changes to the code

12. Test Coverage
Changes that prove your changes work

13. Guidelines

14. Be nice
Don’t be mean, we are all learning

15. Don’t take it personal
Any code can be improved

16. KISS
Solve a concrete problem now

17. Refactor
You can always refactor later

18. Don’t design for
the future
You’re not an oracle, neither am I

19. Document
Any public interface should be documented (YARD)

20. Check Guidelines
We should all follow our style guidelines

21. Functionality
Does it do what it says it does?

22. Performance
Is the code really performant?

23. All Pull Requests
Must Be
Peer Reviewed

24. THANK YOU!
questions?