The document outlines best practices for code reviews and deployment processes within a development team. Key rules include trusting no one, reviewing often, and merging responsibly to ensure code quality. The importance of collective ownership, consistent coding practices, and proper usage of tools like GitHub and GitLab is emphasized.

1. If review is not done,
deploy you should not
May the 4th 2017 VilniusPHP meetup

3. Developer I am
Žilvinas Kuusas
11+ metų programuoju
Sprendžiu el. parašo problemas -
Estina / ISIGN
Mokau/konsultuoju programuotojus
CleanPHP.lt
Skatinu bendruomeniškumą per
VilniusPHP.lt, Symfony.lt,
NoTrollsAllowed.com

4. Pre-merge code reviews

5. It’s “code inspection”

6. 5 rules
of code
reviews

7. Rule #1
If problem is not solved
code exist should not

8. Rule #2
Push to the master
you should not

9. Rule #3
Trust no one you should
(even yourself)

10. Rule #4
Review often, review work in progress

11. Rule #5
Merge responsibly you must

12. Where to start?

13. Small tasks

14. Acceptance criteria

15. Atomic commits

16. Tests

17. Pull requests

18. Integrate frequently

19. Pair on merges

20. Solve the Problem
Before Coding

21. Things to avoid

22. Blind Merge

23. One person responsible for everything

24. No one can push to master

25. Excuses

26. Cowboy coders

27. Focus on details with low value

28. Blame you should not

29. Do not be defensive

30. Review checklist

31. Unit tests

32. Does the code solve the given problem?

33. Method arguments

34. Null References

35. Conventions and Consistency

36. Disposable things

37. Security

38. Finally - accept code by merge

39. Tools
● Github
● Gitlab
● Phabricator
● ...
● ReviewBoard
● BarKeep
● Gerrit

40. Collective ownership

41. Everybody knows...
● what the code does
● why it’s designed that way
● how everything works

42. Bus Factor
no single team member is a bottleneck

43. Shared best practices

44. Consistent code

45. Reusable code

46. Team maturity

47. Ready to create
your first pull-request
you are