8. Code Reviews

Question 1

What can be reviewed

Answer 1

1. application source code
2. source code and documentation
3. test code
4. design description
5. requirement specification

Question 2

Why undertake code reviews

Answer 2

1. detect defects in software
2. identify refactoring opportunities for poorly structured code
3. develop a shared understanding of code between developers
4. share good practices
5. gain knowledge about legacy items

Question 3

When to code review

Answer 3

1. periodic on a portion of the accepted code base
2. on a proposed change to a codebase
3. before a proposed change to a legacy item

Question 4

defect detection rate formula

Answer 4

total defect = method defects + undetected defects

defect detection rate = defects / total defects

Question 5

code review workflow

Answer 5

1. developer initiate change proposal(merge request)
2. developer nominate a reviewer
3. Reviewer review change
4. reviewer submit a recommendation
5. developer makes changes and sends back for review
6. reviewer approves

Question 6

good practice for merge request

Answer 6

keep merge request small

• single review should have about 300 lines of code max
• possible to complete within 30mins
• break larger merge requests in smaller change packages
• incorporate review time to team workload model

Question 7

Describing the change for merge requests

Answer 7

1. give it a title
2. explain the purpose of change(corrective, adaptive, perfective, preventive)
3. report wider impact of change

Question 8

what to automate

Answer 8

1. block merge request that do not conform to standards
   - max size
   - break test
   - code styles violation
   - commented-out codes
   - spelling mistakes
2. static and dynamic analysis for locating “smells”(code with bad practices)
   - source code metrics
   - design metrics
   - test suite metrics
3. create merge request template to ensure consistency

Question 9

static analysis tools

Answer 9

1. design metrics
   - used to identify part of system that are poorly structured
2. source code metric
   - number of lines of code per function
   - ratio of executable vs comments
   - number of spelling mistakes
3. software process metrics
   - number of changes per commit
   - number of defeats discovered

Question 10

questions to ask for code reviews

Answer 10

1. purpose
   - does this solve the problem
   - how would I solve this problem
   - has the documentation, user-guide been updated
2. quality assurance
   - what are the typical, extreme cases and are they covered in test cases
   - what are the corner cases
   - are the test organised and readable
   how does it handle exceptional situations
3. architecture
   - does the change follow the existing architecture
   - are there missed opportunities for reusing existing code
   - are there clones
4. code
   - do identifier follow project naming convention
   - is code self-documenting
   - are all comments necessary
5. non-functional consideration
   - are performing optimisation possible
   - are efficiency optimisation possible
   - are security patterns followed

Question 11

Google code review process

Answer 11

1. ownership
   - tree structure with explicit ownership by set of people
2. readability
   - code styles and norms within workflow
3. code review
   - lightweight review by author and reviewer
4. suggesting a review
   - minimal set of reviewers suggested by tools to fulfil the requirement
5. code analysis result
   - automated tools used to provide additional comments to support reviewers

Question 12

Google Modern lightweight review flow

Answer 12

1. creating
   - author make changes, create a change request
2. previewing
   - author preview the changes and results of the automatic code analyser. the change request is sent to one or more reviewer
3. commenting
   - reviewer analyse code, add comments. the author responsible to take action for unresolved comments
4. addressing feedback
   - author made changes, reply to comments
   - all changes snapshotted, cab be seen by the reviewer
5. approving
   - reviewer approve changes and mark the code review as LGTM
   - changes reflected with at least a few review approvals

Question 13

Google review frequency

Answer 13

about 3 changes/week
less than 7 changes/week for 80% of authors
abut 4 changes reviewed/week
less than 10 changes reviewed/week for 80% of reviewers

Question 14

Google review speed for small and large changes

Answer 14

less than 1 hr for small changes

ard 5 hrs for larges changes

Question 15

Good review size

Answer 15

more than 35% is single file modification

about 90% has less than 10 file modification

Question 16

Google: number of reviewers and comments

Answer 16

99% of changes with 1 to 5 reviewers
12.5 comments per change
1250 lines per change

Question 17

developer perception

Answer 17

1. geographical and organisational distance as the cause of delays or misunderstanding
2. tone and power in social interaction heading to uncomfortable frustration in the process
3. mismatched expectations in review causing frictions
4. context misunderstanding resulting in delays and frustration
5. differences in customisation may cause misunderstanding