1. Code Reviews From Hell
And Automatizations

2. About me Software Developer at Reputation Institute. Traveler / foodie
Colorblind
I hate describing myself.
@karloslupus

3. Where I work?

4. How many of you do code reviews?
Question
How many of you do code reviews?

5. About this talk It's not about clean code practices.
It is about reviews itself:
Intro about code Part 0
Bad experiences Part 1
Insights Part 2
Tools Part 3

6. 0/3 Intro about Code

7. There is no perfect code

8. Code and Context

9. Code and Context II

10. Code and Context III
Does your code talk business? (Ubiquitous language)
What’s the business value?
Are you aware of the strategy of your company?

11. Does your code talks business? (Ubiquitous language)
Striving to use the vocabulary of a given business domain, not only in discussions about the requirements for a software product, but in discussions of design as well and all the way into "the product's source code itself".
COMMON LANGUAGE

12. What´s the business Value?

13. Are you aware of the strategy/product of your company?
Domain Discovery Techniques?
Strategy Maps?
Wardley Maps

14. THE MORE ..THE BETTER CODE
Code and Context III
Does your code talk business? (Ubiquitous language)
What’s the business value?
Are you aware of the strategy of your company?
THE MORE ..THE BETTER CODE

15. Best practices? Best practices changes over time.
Only these ones seems to be static is:
TEST YOUR CODE
Try to be framework agnostic.
Develop for humans.
Isolate the Domain/Business logic.

16. 1/3 Code Reviews the perfect killer.

17. Once Upon a time... Best Company ever:
- 2 weeks + 1 week onboarding (travel to headquarters)
- Incredible welcome (Champagne bottle, book about the company, gift cards from places around, etc..)
- NetFlix Organization (Full stack autonomous teams vs Guilds)
- Real Scrum (agile process)
- Implementing DDD + TDD + MicroServices
- Human Qa's team.
- Amazon partners. Incredible devops team.
- Best Parties !

18. But.. one little problem...strange things

19. Organization vs Reality
NetFlix teams war's (blue against yellow, yellow against blue, red against yellow, etc..)

20. All kind of trolls
The empty line troll (yes, an empty line between methods breaks the code)
The grammar nazi troll or naming ( I don't like this name, pr stopped, 2 days later, ahh yes, well it's good enough thumbs up )
The ddd troll (even in legacy code, a controller with 2500 lines, you added a method with 25 and was a disaster… it really was?)
The father of the trolls, the first of his name (Sending other people, arguing about a method copied from his own code uploaded 3 days ago..etc..)

21. 2/3 Better Reviews. Knowing your enemy

22. Facts About Code Review
Source:
# of Files Analysis
Given: (almost same lines per file) ====> THEN:

23. Conclusions:
1 - We only really do good reviews with commits < 2-3 files. Our focus lost after 10 files.

24. Facts about Code Review 2
Source:
What about lines??

25. Conclusions:
1 - We only really do good reviews with commits < 2-3 files. Our focus lost after 10 files.
2- After 100 lines we are really good and fast as reviewers!!!
2- After 100 lines we are really BAD but fast as reviewers!!!

26. Facts about Code Reviews 3
What about # of reviewers?
More reviewers -> less time per reviewer (another will find some problem)
More reviewers -> More possible bugs!!

27. Conclusions:
1 - We only really do good reviews with commits < 2-3 files. Our focus lost after 10 files.
2- After 100 lines we are really BAD but fast as reviewers!!!
3- Choose 2-3 Reviewers

28. Not evidence based advices:
Everyone:
Review the meanings, not the format. Choose a style guide and apply automatic tools for that
Positive aptitude, it's not personal. (it's just your f$%ˆing code)
Reviewers:
Review everything!
Choose and adapt a checklist:

29. Not evidence based advices II
Submitters:
Split the issues / commits if there is more than 200 lines. (100 is the best) (Less than 3 files).
Provide Context: provide description, documentation, tests!!
Better talk than start a codereview war.
Pass automatic tools before submitting.

30. If you want to be a troll Review a few lines and:
Suggest better naming
Suggest refactor (you can always refactor more)
Suggest break of some SOLID principle
Or just say "This is not clear"

31. 3/3 Automatic Tools

32. Some of them
Style: Php-cs-fixer:
Linter: phpLinter:
Php mess detector:
Static Analysis: PhpStan:
Static Analysis: Psalm:
Copy Paste Detector (Carefull DTO's):
etc..

33. IN each commit
You should run all of them! (same codestyle across the project)
Check your tests (phpunit, behat, phpspec..)
Check Composers problems (composer.json without composer.lock)
Established defaults (default headers, strict declare, namespace sorts, etc..)

34. Some tools to do all of this:
(dependencies on the project, defaults files created on the project)
There are a lot more…. but
Which one is the best??

36. Conclusions

37. Questions??
THANKS!!