编程辅导 SOFT2201/COMP9201:

The University of 1

SOFT2201/COMP9201:

Copyright By PowCoder代写 加微信 powcoder

Software Design and
Construction 1

Code Reviews

School of Computer Science

The University of 2

Announcement

– We will do an interactive code review session guided by your
tutor during this week’s tutorial
– Pair programming will be used during the tutorial. Please

have a look at the preview-recommendation page on
canvas (under module 8) before you go to your tutorial

– An announcement could be found on Ed regarding the
reschedule of tutorials on Thursday (which will be a public

The University of 3

– Why review

– What to review

– What is a review

– What is a formal review

– What is an informal review

The University of 4

Why review?

The University of 5

Why review?

– What is the software, or aspect of the software, to be
reviewed for?
– What are the specifications that need to be met?

– Does the software, or aspect thereof, being reviewed,
meet those specifications?

The University of 6

What is the software for and does it work?

– What is the software, or aspect of the software, to be
reviewed for?
– What are the specifications that need to be met?

– Does the software, or aspect thereof, being reviewed,
meet those specifications?

– We need a way to check that the software is
appropriately designed to meet the expected criteria

The University of 7

What to review?

The University of 8

What to review?

– Any part of a software project can be reviewed
– Documentation
– Processes
– Management
– Specifications
– Planning

The University of 9

What is a review?

The University of 10

What is a review?

– A software review is
“A process or meeting during which a software

product, set of software products, or a software process
is presented to project personnel, managers, users,
customers, user representatives, auditors or other
interested parties for examination, comment or approval.”

IEEE Standard 1028-2008, “IEEE Standard for Software Reviews”, clause 3.5

The University of 11

formal review?

The University of 12

Fagan inspection

– An early effort to formalise the process of reviews
– The basis, or at least similar, to subsequent formal

approaches
– Describe program development process in terms of

operations
– Define ‘entry’ and ‘exit’ criteria for all operation
– Specify objectives for the inspection process to keep

the team focused on one objective at a time

The University of 13

Fagan inspection

– Classify errors by type, rank by frequency, identify
which types to spend most time looking for

– Analyse results and use for constant process
improvement

The University of 14

Fagan inspection operation

– Specify objectives for the inspection process to keep
the team focused on one objective at a time
– Planning
– Overview
– Preparation
– Inspection
– Follow-up

The University of 15

Fagan inspection operations
– Planning

– Preparation of materials
– Arranging of participants
– Arranging of meeting place

– Overview
– Group education of participants on review materials
– Assignment of roles

The University of 16

Fagan inspection operations
– Preparation

– Participants review item to be inspected and supporting
material to prepare for the meeting, noting any questions or
possible defects

– Participants prepare their roles
– Inspection meeting

– Actual finding of defect

The University of 17

Fagan inspection operations

– Rework is the step in software inspection in which the defects
found during the inspection meeting are resolved by the
author, designer or programmer. On the basis of the list of
defects the low-level document is corrected until the
requirements in the high-level document are met.

– Follow-up
– In the follow-up phase of software inspections all defects found

in the inspection meeting should be corrected. The moderator
is responsible for verifying that this is indeed the case. They
should verify that all defects are fixed and no new defects are
inserted while trying to fix the initial defects.

The University of 18

Formal inspection

– Management review
– Monitor progress
– Determine status of plans
– Evaluate management effectiveness
– Supports decisions about changes in direction, resource

allocation, and scope

The University of 19

Formal inspection

– Management review
– Maintenance plans
– Disaster recovery
– Migration strategies
– Customer complaints
– Risk management plans

The University of 20

Formal inspection

– Management review roles
– Decision maker
– Review leader
– Recorder
– Management staff
– Technical staff

The University of 21

Formal inspection

– Management review processes
– Preparation
– Plan time and resources
– Provide funding
– Provide training
– Ensure reviews are conducted
– Act on reviews

The University of 22

Formal inspection

– Technical review
– Software requirements
– Software design
– Software test documentation
– Specifications
– … procedures

The University of 23

Formal inspection

– Technical review roles
– Decision maker
– Review leader
– Recorder
– Technical reviewer

The University of 24

Formal inspection
– Inspections

– The purpose of an inspection is to detect and identify software
product anomalies. An inspection is a systematic peer
examination that does one or more of the following:
• Verifies that the software product satisfies its specifications
• Verifies that the software product exhibits specified quality

attributes
• Verifies that the software product conforms to applicable

regulations, standards, guidelines, plans, specifications,
and procedures

The University of 25

External Audits
– Reviews may also be performed by external groups

– A formal process is generally highly desirable when dealing
with external groups and may extend any of the above
approaches

The University of 26

What is an
informal review?

The University of 27

Informal reviews
– Reviews may be far less formal

– Pair-programming
– “Over the shoulder”
– Walkthroughs
– Presentations
– Self-guided reviews
– Checklists

The University of 28

Informal reviews
– Formal reviews are far more effective than informal

– Informal reviews are far more convenient than formal

The University of 29

How about a
semi-formal
code review?

The University of 30

– Have a clear purpose for the review
– Identify all relevant project specifications
– Identify how the specifications can be verified
– Identify who the relevant stakeholders are

The University of 31

Change List/Pull Request reviews
– A complete, ‘working’ project exists
– A set of changes are to be applied
– The changes must be reviewed before they are

The University of 32

Change List/Pull Request reviews

– Is this change wanted?
– Technical reviewer

– Does this change work?
– Technical reviewer

– Is this change maintainable?
• (Can I understand it?)

The University of 33

A brief visit to Design by Contract (DbC)

– A software design approach for program correctness

– Also known as contract programing, programming by
contract, design-by-contract programming

– Definition of formal, precise and verifiable interface
specification for software components
– Pre-conditions, postconditions and invariants (contract)

The University of 34

Reviewing DbC change lists

– Definition of formal, precise and verifiable interface
specification for software components
– Pre-conditions, postconditions and invariants (contract)

– Are the pre-conditions met?
– Are the post-conditions met?
– Are the invariants invariant?
– Are these likely to stay so?
– How hard is it to verify?

The University of 35

Change List/Pull Request reviews

– Does the documentation agree with the specifications?
– Technical reviewer

– Are there tests?
– Do the tests verify the pre/post conditions are met?

– Technical reviewer
– Is the code written according to the style guide?
– Does the code use appropriate design patterns?

The University of 36

Change List review challenges

– The more there is to read, the more scope there is to miss

– Many small code reviews are more manageable (somewhat
like unit tests vs blackbox system tests)

– A large code review can take so much time that special
planning is needed

– May need to place limits on acceptable sizes for review

The University of 37

Change List review challenges

– Changes that affect many processes may need more
reviewers for the required technical knowledge

– May sometimes be helped by multiple, smaller changelists
– May bring specifications from different processes into conflict,

requiring management review
• May also be triggered by small changes with big impacts,

such as changing JDK version

The University of 38

Change List review challenges
– Complexity

– Fast, efficient, code may be hard to read and hard to
understand

– Is the code complexity, thus review complexity and
maintenance complexity, worth the improvement?

– Does the complexity affect maintainability and testability?

The University of 39

Change List review challenges
– Confusion

– What is the change meant to be for?
– May be doing too many unrelated things
– May be making unnecessary changes
– May even be about a disagreement between colleagues (my

approach is better!)

The University of 40

Change List review techniques
– Formalise the review process

– All changes must be reviewed
– We already have review roles – Owner, Readability, Technical
– The planning and preparation are only needed once per

project (plus for each major change in direction)
– The project needs clear specifications, requirements, and

sufficient documentation
– The CL must meet the requirements
– Changes are recommended and either acted on or disagreed

with and the result re-evaluated

The University of 41

Change List review comments
– Be clear
– Be objective
– State the issue
– State what is needed to fix it

– E.g., “Document this method”
– E.g., “These braces aren’t needed, please remove”
– E.g., “Split this file into one per class, for readability”
– E.g., “Use informative variable names”

The University of 42

Change List review examples
– This needs tests
– This needs unit tests
– This needs integration tests
– This needs documentation
– What is this for?
– This doesn’t follow the style guide
– Resubmit without the temp files

The University of 43

Change List review techniques
– Automation is great!

– When it works
– Code style
– Coverage
– Test suites
– Performance tests
– Spelling (A little more challenging in code)
– Common code issues

The University of 44

Reviewing larger projects
– You may need to review larger projects, rather than

– A formal review process will ensure all parties

understand what is expected
– The code inspection will be similar to a changelist

review, but with no existing base to compare to
– More work is needed to verify requirements

The University of 45

Change List review comments
– E.g., “Document this method”
– E.g., “These braces aren’t needed, please remove”
– E.g., “Split this file into one per class, for readability”
– E.g., “Use informative variable names”

– A report on a set of changes would discuss why the
comments were made, the benefits, the problems, and
discuss other approaches

– A code review is far more concise and directed

The University of 46

Task for Week 8

– Additional presentation video about code review on project
can be found on canvas (Recorded Lecture section)

– Submit weekly exercise on canvas before 23.59pm Saturday
– Attend tutorial on time for an interactive code review session

guided by your tutor during tutorial

The University of 47

What are we going to learn on week 10?

• Creational Design Pattern
– Prototype

• Behavioral Design pattern

Attention Please: due to Monday of week 9 (3 Oct) is a public
holiday, we don’t have lecture on week 9. BUT we still have
tutorials on week 9.

The University of 48

References

– Fagan, M. E. (1976). “Design and code inspections to
reduce errors in program development”. IBM Systems
Journal. 15 (3): 182–211. doi:10.1147/sj.153.0182

– IEEE Std . 1028-1997, “IEEE Standard for Software
Reviews“, doi:10.1109/IEEESTD.2008.4601584

https://doi.org/10.1007%2F978-3-642-48354-7_14
https://doi.org/10.1109/IEEESTD.2008.4601584

程序代写 CS代考 加微信: powcoder QQ: 1823890830 Email: powcoder@163.com