As developers we always look for ways to do things faster, better, and automate as much as possible. We write code in top-notch IDEs that have static code analysis, automatic refactoring and so on, we run unit tests, we use CI servers, and issue trackers, we adopt agile practices to get feedback and deliver as fast as possible. As far as code review practice goes, there’s still a lot to be improved, and in this talk I’m going to tell you how you can perform efficient, transparent and useful code reviews.

1. HOWTO STOP WASTINGYOURTIME AND
START PERFORMING USEFUL CODE
REVIEWS
Maria Khalusova, JetBrains
@mariakhalusova

2. CODE REVIEW

3. https://twitter.com/pcweenies/status/649954658794913792

4. CONTENTS
• Smooth start
• Making code reviews useful
• What to look for in a code review
• Human factor

5. WHERETO START

6. THETEAM
• Communicate clearly.
• Listen to concerns.
• Cultivate code review culture.

8. PROCESS
• Decide on the process
• Keep workflow simple
• Iterations are good
• Average of 2 reviewers
• Do reviews often

9. NEWTOOL
• Yes, you need a code review tool
• Find the right tool for you:
Fits in your environment
Supports chosen workflow
Meets your particular needs
Keeps you in the loop without spamming

10. SUMMARY
• Have an open dialog with the team
• Have a good plan
• Find a tool

11. MAKING CODE REVIEWS
USEFUL

12. AUTOMATE WHAT CAN BE
AUTOMATED
• Tests
• Continuous Integration
• Static code analysis
• Spellchecker
• etc.

13. Code review is not a place for coding style wars

14. AS A CODE AUTHOR
• Review your own code
• Commit small changes
• Document your code
• Write meaningful commit message

15. AS A REVIEWER
• Don’t delay the review
• Don’t spend too much time
• Apply your expertise

16. KNOW WHATTO LOOK FOR

17. GENERAL AND BUSINESS
LOGIC
• Correctness
• Coding errors
• Business logic and rules
• User-facing messages

18. ARCHITECTURE AND DESIGN
• Is the code in the right place?
• Complexity
• Reusability
• Data structures

19. READABILITY &
MAINTAINABILITY
• Naming
• Readability
• Test coverage
• Documentation
Always code as if the person who ends up maintaining your code is a violent
psychopath who knows where you live.
- John F. Woods (1991), Martin Golding (1994)

20. PERFORMANCE
• Performance requirements
• Performance tests
• Unnecessary network calls
• Potential memory leaks

21. SECURITY
• Review potential problems
• Third party libraries
• Authentication
• Data encryption
• Proper management of passwords, encryption keys, etc.
• …

22. SECURITY: USEFUL READ
• Common weakness enumeration: CWE.mitre.org
• OWASP.org
Code Review Guide Book v. 2.0 ALPHA

23. HUMAN FACTOR

24. https://twitter.com/msdevUK/status/644136657311113216

25. https://twitter.com/ankitsadana1/status/651473349319766016

26. LEARNTO GIVE FEEDBACK
• Don’t be rude
• Don’t dictate, ask questions, engage in a discussion
• It’s ok to disagree and argue
• Do not teach
• Be sensitive to cultural differences

28. LEARNTO RECEIVE FEEDBACK
• Contain your immediate reaction
• Consider suggestions
• Ask followup questions

29. IT DOESN’T HAVETO BE ALL
CRITICISM
PRAISE GOOD WORK

30. THANKYOU!
QUESTIONS?
maria.khalusova@jetbrains.com
@mariakhalusova