Code Review - a checklist to do it right

Overall: Look for Improvement - Do Encouragement - Share best practices - Not to hold the PR - Minor things should be noted but tell developer it's skippable.

1. Design:
   Does the code change make senses? is it a good time to add? how does it integrate with our current code base or system?
   
   
2. Functionality
   Determine the users of this code change: both end-users (feature impact) and developer (future use, future enhancement?)
   Ask for a demo/UI if need to understand the reason
   Introduce a race condition or deadlocks?
   
   
3. Complexity
   Functions are too complex?
   Classes are too heavy?
   “Too complex” usually means “can’t be understood quickly by code readers.” It can also mean “developers are likely to introduce bugs when they try to call or modify this code.”
   Over-engineering: code is more generic than it needs to be, solving a future problem? future problems should be solved when it arrives not the time of PR.
   
   
4. Test
   Ask for Unit tests, integration tests, end-to-end tests
   Test should never test itself
   Tests are code so that they are need to be easily maintained
   
   
5. Naming
   Naming is hard, should pick a good name: descriptive and describe correctly the purpose
   
   
6. Comments
   Comment WHY not WHAT to do
   Check the necessary of the comments
   Need to be a clear and understandable ENGLISH (don't use Japanese)
   Comments are different from documentation
   
   
7. Styles
   Follow Swift Lint rules https://realm.github.io/SwiftLint/rule-directory.html
   Run SonarQube before making the PR, always check SonarQube results after PR made
   
   
8. Documentation
   Should always be updated with the code
   Delete if code is deleted
   Update README in case new code violates it
   
   
9. Every line
   It's a must to go through every line of code that have been assigned to you.
   Some codes are auto generated, but never skip human-written code.
   For large code base, break into parts to review, note in comment for the part that reviewed or mark reviewed using Gitlab interface then can continue at another time.
   Ask for clarification if any codes slow down your review.
   
   
10. Context
    Sometimes need to have a broader context to tell code changes make sense: for example several lines are changes, but need to read whole class to decide correctly.
    Don’t accept PRs that degrade the code health of the system
    
    
11. Good thing
    If see something nice in the PR, tell the developer. Code reviews often emphasize on mistakes, but should offer encouragement and appreciation for good practices.

Based on https://google.github.io/eng-practices/review/reviewer/looking-for.html